I got tired of pasting client documents into ChatGPT and hoping for the best

The "trust gap from GPT glue-coding" wedge is real. How did you handle showing users what context the model saw? My early testers wouldn't trust the output until I exposed the actual SQL + sources inline — felt counterintuitive but conversion shifted.

This healthcare thread is spot on. I hit the same wall with HealthOS — a voice app that reads your nervous-system state. Decided early that audio never leaves the phone. Users weren't asking for it; I just knew that the moment you say "sends to cloud" in anything health-related, the trust-sensitive people walk, and you torch any shot at clinical validation down the line.

Your browser-side redaction approach is the same instinct — keep the sensitive work where the data already lives. What have compliance teams made of it so far?

Honestly, I think it depends a lot on who's using it. As someone building apps and using AI tools constantly for code, prompts, etc, I don't think about it much for my own stuff since it's not sensitive. But for what you're describing, contracts with real names and IBANs, that's a different level entirely, and I'd guess most people genuinely don't realize they're sending that until someone points it out like you just did.
I think the "nobody loses sleep over it" feeling is more about awareness than not caring, once people see it laid out like this, I'd bet a good chunk would care. Curious if you've gotten that reaction from people you've shown this to.

Honest answer: the pain is real, but it's lopsided, and the split matters for how you sell it.

We build AI agents for regulated industries at Ojin (banking, healthcare, tourism), and the pattern is stark. Individuals mostly nod. They agree it's bad, then paste the whole doc anyway because convenience wins every time. That group is hard to monetize.

In regulated B2B it's a different universe. It's not "losing sleep," it's a hard gate. The first question in every enterprise conversation is some version of "where does the data go and what do you retain." Deals stall for months on exactly this. A client name and an IBAN reaching a third party isn't a vibe, it's a compliance violation with a number attached. Anyone under GDPR handling client documents feels it daily.

So I'd validate by who, not whether. The freelancer pasting a contract feels it for three seconds. The compliance officer who has to answer for the whole team's pasting habits feels it constantly, and has budget.

One back at you: are you positioning ArcanAI as a personal browser tool or as something a firm can mandate across a team? The people who actually lose sleep are the ones accountable for everyone else's behavior, not the individual doing the pasting. That choice changes your whole go-to-market.

Honest answer from years in the Microsoft partner and MSP world, selling into compliance-heavy orgs: for individuals and small teams, this is a 'nod but don't lose sleep' problem. They want speed, not safety. But you're not really selling to them. In regulated orgs (legal, finance, healthcare) someone absolutely loses sleep over it, it's just not the person pasting the document. It's the security or compliance lead who has to sign off on the tool, and right now their honest answer to 'can we use ChatGPT on client files' is no. I watched plenty of good deals die not because the product was weak but because it couldn't answer 'where does the data go' on a security questionnaire. Browser-side redaction is a clean answer to that exact question. So I'd flip the positioning: the end user wants it faster, the buyer wants to not get fired. Sell to the second one. The free no-credit-card plan is fine top of funnel, but the money is the team that needs this to say yes to AI at all.

The two-confidence-problem framing in the comments is sharp. There's a parallel in healthcare dictation that I run into constantly. Clinicians want to dictate notes into their EHR but the audio can't leave the device - PHI, HIPAA, all of it. So they're stuck typing or using ancient on-prem Dragon installs. The confidence problem there is the same split: confidence that the data stays local, and confidence that the transcription is actually accurate for medical terminology. I built DictaFlow Medical to handle both - local processing so nothing leaves the device, and medical-specific models for accuracy. It's the same pattern you're describing with document sanitization: don't block the AI use case, just make it safe by default. Curious if you've had healthcare folks reach out about your tool - seems like it'd be a natural fit for clinics.

This is a real concern that most people quietly ignore. The "I'll just paste it in" habit is universal and nobody thinks about what's on the other end until something goes wrong.
The interesting thing is it's not just about privacy policy trust — it's about habit. People paste first and think later. Your tool solves a problem that exists before the user even recognizes they have it, which is a hard sell but a strong product if you can get the first use moment right.
To answer your question honestly: most people don't lose sleep over it until they have a reason to. One data breach story in their industry and suddenly everyone cares. That might be your distribution angle — not "protect your data" but "here's what happened to someone who didn't."

The "confidence" framing in this thread is more accurate than "privacy" and I'd push it one step further.

There are actually two confidence problems for professional AI use, usually treated as one.

The first is what you're solving: confidence that sensitive data doesn't leave in the wrong form. Real problem, clearly painful for anyone with compliance exposure.

The second is less visible: confidence that the output is actually right for your specific situation. Not technically accurate but operationally relevant. The AI analyzed the contract correctly but had no idea about the relationship history with this client, your standard negotiation boundaries, or the three things your firm always flags in this type of agreement.

Both produce the same symptom: professionals not trusting AI enough to remove themselves from the loop. But they need different fixes.

What's interesting about the regulated verticals you're describing (legal, finance, healthcare) is that they have both problems acutely. The privacy one is visible and creates liability. The operational relevance one is invisible but drives the "I still have to rework everything it gives me" frustration that keeps AI stuck as a drafting assistant instead of a real workflow change.

Curious whether you're seeing the second problem come up in user conversations.

This is actually a more common concern than it seems, especially in legal, finance, and consulting where sensitive data is involved.

Most people don’t really think about what they paste into AI tools, but when it comes to client documents, the risk feels very real. Even if nothing “bad” happens, the idea of sending personal or financial data to external servers creates hesitation.

What’s interesting about your approach is that it doesn’t block AI use, it just makes it safer by default. That’s a more practical solution than telling users to change their behavior.

I think the pain is very real for people handling client, legal, or financial documents. The challenge might be that the people who care the most are often the ones with compliance requirements, so trust and proof probably matter as much as the product itself.

The "does anyone actually care" question is
one I keep running into too as a solo builder.
What I've noticed: people don't change behavior
from awareness. They change from a moment —
a bad experience, a close call, a client asking
questions.
You can't manufacture that trigger. But you can
make sure the solution is already there, easy to
use, when it hits.
That's probably your real job right now.

This is a smart approach to a real security concern. Data privacy and compliance are becoming increasingly important, especially with regulations like GDPR and CCPA. The fact that you're handling sensitive data processing locally before any AI analysis is a key differentiator. I'd be curious to know more about your target market strategy — is this positioned primarily for enterprises or SMBs?

the honest answer to your question depends on who you're asking. individual users often don't lose sleep over it even if they say they do. compliance officers, legal teams, and anyone who has had to explain a data incident to a client do lose sleep over it. those are very different buyer conversations and the second group actually has a budget line for this problem. which one are you currently talking to and is the product priced and positioned for individual use or team use

I think this solves a real problem, but the target audience matters.

For casual users, the convenience of pasting documents directly into an AI tool usually outweighs privacy concerns. Many people simply trust the provider or don't think about what data they're sharing.

For professionals—lawyers, accountants, consultants, HR teams, healthcare workers, finance professionals, and anyone handling client data—the concern is very real. In those environments, it's often not just about personal discomfort; it's about compliance, confidentiality, and contractual obligations.

The challenge may be that people don't wake up thinking, "I need document anonymization." They feel the pain when they're about to upload a sensitive document and hesitate. Your product could be strongest when positioned as a way to use AI safely with confidential information, rather than as a generic privacy tool.

One thing I'd be curious about: how well does the anonymization preserve context? If the AI can still accurately analyze contracts, financial reports, and other structured documents after names and identifiers are replaced, that's where the real value lies. Privacy is important, but maintaining output quality is what will make people adopt it.

this is a real problem, not a theoretical one. most people I've talked to about their AI workflows have zero process for checking what they're sending — they just paste and go. the 'does anyone actually care' question is interesting because it's usually not that people don't care, it's that they haven't thought about it. the moment you show someone their IBAN sitting in a ChatGPT prompt history they care a lot. the gap is awareness not apathy.

The local-first part is the whole thing. I talk to a lot of freelancers and small agencies, and the unspoken blocker to AI adoption isn't capability, it's 'where does my client's data actually go.' The moment a contract with names and IBANs leaves the browser, half of them quietly stop using the tool. A redaction step that provably never sends raw PII to the API isn't really a feature, it's the permission slip that lets a whole category of sensitive work touch AI at all. Curious how you handle false negatives though, the one IBAN the regex misses is the one that matters.

Mechanically this is the right instinct — strip the PII client-side so the model only ever sees [NAME_1], and the real identity never makes the trip. That's a fundamentally stronger guarantee than a privacy policy, because you're not asking anyone to trust a promise, you've removed the data from the path entirely. I made the same call building a small iOS memo app solo: keep the sensitive processing on-device so nothing private leaves the phone in the first place, even for things like turning speech into text. The hard part you'll hit isn't the redaction, it's the edge cases — a name embedded in a sentence, an IBAN split across a line break. People say they want privacy, but what actually earns trust is an architecture that makes the leak impossible rather than merely unlikely.

The privacy information is very critical. I sometimes forget about it too. How did you build with the backend?

To answer your honest question: yes, it's a real concern — but only for a specific subset of users who've already had the uncomfortable realization you described.

We ran into this same wall building Swiftbill (invoice generator for freelancers). Our users handle client names, addresses, bank details, payment terms. When we originally designed the PDF generation to run server-side, early users pushed back hard. "Why does my client's payment info need to touch your server to make a PDF?" They were right.

We moved the entire PDF generation into the browser with pdf-lib. Nothing leaves the device. That one change removed a category of objection completely.

What you're building solves a real problem — the question is whether users feel the pain before a breach or only after. My guess: freelancers and consultants who deal with client financials feel it acutely. People processing their own notes probably don't. The ICP matters a lot here.

I actually think about this a lot. Building a family budgeting app made me realize that financial data is one of the hardest things to ask people to share. Trust is probably a bigger challenge than the product itself.

Honestly I'm in the "nod and keep pasting" camp, but only because nothing made it easy. Stripping it in the browser before it leaves is the part that'd actually change my behavior.

I wonder if the pain isn't privacy itself but confidence. Most people don't know what they can safely upload, so they either overshare or avoid using AI altogether. A tool that removes that uncertainty could be valuable even beyond the privacy angle.

People care in proportion to how close they've been to an incident. Most nod; the ones who've had a client ask "where did our data go" feel it in their gut. What gets underweighted: it isn't only what OpenAI sees. That same raw document usually also lands in your own logs and whatever vector store you're indexing it into. Stripping PII before it leaves the browser shuts the loudest door, but the copies inside your own stack are where it tends to pile up unnoticed. Worth deciding what you retain, not just what you send.

This resonates a lot. I ran into a related issue from the other direction after getting output back from ChatGPT/Claude, it's often full of markdown clutter, "As an AI..." phrases, and formatting that needs cleanup before I can actually use it in client deliverables.
Ended up building a small free tool (AiCleanerText) to handle that cleanup automatically. Curious what approach you landed on for the document-pasting side did you build something custom, or use existing tools/APIs to structure the input better?

To answer your question: it depends entirely on the vertical, not the individual.

Solo founders building in public? They don't care at all. The data is already public.

Legal, finance, healthcare? They care intensely. Not because of personal ethics but because a data incident creates liability. The decision isn't "should I protect client data" it's "what happens to my business if I don't."

I ran into the same constraint building Genie 007. It processes voice in the browser rather than sending audio to a server because some users flat-out won't use a tool that phones home. The local processing became a selling point, not just a technical choice.

You might find your strongest early traction in a specific regulated vertical rather than the broad "AI users" category. Accountants handling client financials. Paralegals reviewing contracts. The problem is urgent for them in a way it isn't for general users.

I'd be careful treating this as a privacy question too quickly.

The interesting question may not be whether people care what the AI sees.

It may be what has to be true before they're willing to change their current behavior.

Those sound similar, but they can lead to very different conclusions about the problem, the buyer, and the validation signal.

I wouldn't make that call casually from the current feedback.