How to Use Frontier AI on Files Too Sensitive to Upload
A redaction-based workflow lets you use frontier AI on confidential files by stripping PII first, keeping only what the task needs.
What’s the actual problem with uploading sensitive files to AI?
Frontier AI models need real context to do useful work, and real context usually lives inside the documents people are told never to upload. A contract, a performance review, a customer file, an operating plan. These files contain both the information a model needs to help and the information it has no business seeing, like home addresses, medical notes, API keys, or unreleased prices. The standard advice, “don’t paste sensitive information into AI,” doesn’t tell anyone what to do when the sensitive work still needs to get done. That gap is where a redaction-first workflow becomes useful: strip out what the model doesn’t need, keep what it does, and send only the smaller, cleaned copy.
TL;DR
- Frontier models don’t need entire files, they need the specific facts relevant to the task, and everything else in a document is just along for the ride.
- Blacking out text in the original file isn’t safe, because formats like Word can retain comments, track changes, author metadata, and old edits even after the visible page looks clean.
- The safer pattern rebuilds a new, smaller document from only the approved content, leaving the original file untouched on the user’s machine.
- Redaction has to start with intent, since the same detail (like a price) can be essential for one question and irrelevant for another.
- Verizon’s enterprise telemetry this year showed AI use on corporate devices rising from 15% to 45% every 15 days, with two-thirds of that usage happening through non-company accounts, a sign of shadow IT rather than policy compliance.
- Security fatigue is a known pattern, described by NIST, where too many manual privacy decisions push people toward whatever option is easiest, which is usually the unapproved one.
- Some documents shouldn’t go through any redaction workflow at all, because removing the sensitive parts would remove the reason the task needed AI in the first place.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Why doesn’t “just don’t upload it” work anymore?
That advice made sense when AI use meant asking a chatbot general questions: write an email, explain a concept, brainstorm ideas. None of that required real documents. But the useful work people actually want AI to help with today looks different: the actual proposal being sent, the actual contract under negotiation, the unorganized meeting notes, the real codebase. This is a much larger and messier category of information than a couple of years ago, and it’s exactly the kind of material that makes a model’s output useful. The problem is that this shift happened fast. AI interaction became close to frictionless, while the responsibility for deciding what information can safely leave a company got quietly pushed onto individual employees, with no real training or tooling to support it.
That mismatch shows up in usage data. Verizon’s enterprise telemetry this year found that regular AI use on corporate devices roughly tripled, and a majority of that use happened through personal or unapproved accounts rather than sanctioned company tools. Source code was the most common sensitive material submitted through those outside routes. That’s not really a story about careless employees. It’s a story about the approved path being harder to use than the unapproved one, which is precisely the condition NIST describes as security fatigue: when the number of manual security decisions piles up, people default to whatever is fastest.
How does a redaction-based workflow actually work?
A workflow like this (demonstrated using a tool called Airlock) starts before any document is touched, by defining protected terms. Some sensitive information is obvious to a pattern matcher (emails, phone numbers, addresses). Other sensitive information only looks sensitive if you know the context, like an internal project codename or a customer name that means nothing to a machine but means everything inside the company. Feeding that context in up front lets the system combine standard PII detection with the organization-specific terms a person actually knows.
From there, the tool scans the document and defaults to hiding anything uncertain. Nothing is revealed unless someone actively decides it needs to be included. That default-to-hide posture matters because the actual work of redaction isn’t deletion, it’s judgment. Stripping every name, date, price, and location produces a document that’s safe but useless. The harder and more valuable task is separating facts the model needs to solve the problem from facts that simply happened to be bundled into the file.
Once those decisions are made, the tool builds an entirely new document rather than marking up the old one. That distinction matters more than it sounds. Word files and similar formats are containers that can carry hidden history: old comments, track changes, prior authors, embedded relationships, none of which necessarily disappear just because the visible page looks clean. Rebuilding a clean copy from scratch, instead of editing over the original, avoids that leakage. The original file never leaves the user’s machine. Only the smaller, purpose-built copy goes to the model.
What decides what gets kept versus removed?
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
The task, not the file. The same operating plan might need warehouse migration timing and an ERP integration assumption kept in, because those are the load-bearing facts a model needs to spot risk. It doesn’t need the customer’s home address, private medical notes, an API key, or a price that has nothing to do with the question being asked. Change the question, and the answer changes too: if the task is evaluating pricing strategy itself, the price becomes essential context rather than a discardable detail.
This is also why the same approach can be the wrong choice for some documents entirely. A medical record where the full history is the reason the analysis has value isn’t a good candidate for stripping sensitive details, because removing them removes the task. In that case, the work belongs in a properly governed environment built to handle the full record, or it shouldn’t go anywhere near a general-purpose model at all. Contracts sit closer to the middle: renewal dates and indemnity clauses might be necessary for a risk review, while the signatories’ personal addresses almost never are.
Is this actually solving a privacy problem, or just moving it?
It’s a partial solution, and it’s honest about that. The approach doesn’t try to make every file safe for every model. It narrows the problem to a specific, repeatable question: what does this task actually require, and what is the smallest version of this document that still answers it? That’s a meaningfully different question than “how do I scrub this file,” because the second question has no stopping point and the first one does.
It also doesn’t remove the need for judgment. Someone still has to decide whether a project codename is sensitive, whether a price matters for this particular question, or whether a document belongs in a governed system instead. What changes is that those decisions get made once, deliberately, with the file’s context in front of the person making them, rather than being guessed at under deadline pressure or skipped entirely because the upload button is faster.
Frequently Asked Questions
What’s the difference between redaction and blacking out text in a document?
Blacking out text edits the original file and can leave hidden metadata behind, like comments, track changes, or author history, that survives even when the visible page looks clean. Redaction done properly rebuilds a new document from only the approved content, leaving the original untouched and unshared.
How do you decide what information a model actually needs?
Start with the task, not the file. Ask what the minimum set of facts is that makes the answer useful. A price might be essential for a pricing analysis and irrelevant for a cover email about the same deal. The same rule applies to dates, names, and clauses.
Are there documents this approach shouldn’t be used on?
Yes. If removing the sensitive details would remove the reason the task needs the full record, like a comprehensive medical history, redaction defeats the purpose. That kind of work belongs in a governed system designed for it, or shouldn’t be routed through a general-purpose model at all.
Why are employees using unapproved AI tools despite knowing the risks?
Usage data shows a large share of enterprise AI activity happens through personal or non-company accounts. This tends to reflect approved tools being harder or slower to use than unapproved ones, combined with the pressure to deliver work faster, a pattern security researchers call security fatigue.
Does this replace formal data governance policies?
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
No. It addresses a specific, common situation: a person with a real task and a sensitive file who needs a practical way to get useful AI help without waiting on enterprise-wide policy or tooling changes. Regulated or high-stakes data still needs proper governed systems, not ad hoc redaction.