The uncomfortable truth: AI is a data magnet
AI didn’t invent surveillance, but it sure made collecting and reusing data feel… frictionless. We paste emails into chatbots, record meetings, sync calendars, upload screenshots, and ask models to “summarize this contract real quick.” That convenience is real. So is the risk.
Privacy in an AI-driven world isn’t one switch you flip, it’s a stack of small decisions: what you share, where it goes, how long it lives, and who can train on it. The good news is you can get pretty far with a few habits and a couple of technical guardrails.
This post is meant for NH AI Meetup folks of all stripes—builders, analysts, business owners, curious learners. You don’t need to be a security engineer to tighten things up.
Start with a simple threat model (yes, even for regular humans)
“Threat model” sounds dramatic, like you’re planning a heist. In practice it’s just answering:
- What data am I using? (PII, customer data, internal docs, source code, medical stuff, financial records)
- What’s the worst-case outcome if it leaks? Embarrassing? Legally painful? Competitive nightmare?
- Who do I not want to have it? Public internet, a competitor, an ad network, future model training, even your own vendor’s support team.
- Where does the data go when I use AI? Device → app → vendor servers → subcontractors → logs → training pipelines. Sometimes it stops early, sometimes it keeps going.
If you’re a business leader, do this per workflow: “sales email drafting,” “support ticket summarization,” “HR policy Q&A,” etc. If you’re a developer, do it per dataset and per environment.
The main privacy risks with AI (in plain English)
Let’s name the big ones so you know what you’re defending against.
1) Data used for training (or retained for review)
Some services use prompts and uploads to improve models unless you opt out. Others claim they don’t train, but may still retain data for abuse monitoring or debugging. Retention isn’t always bad, it’s just… a place your data can exist.
2) Prompt leakage and oversharing
This one is on us. People paste secrets because the tool feels like a private notebook. It’s not. Even if a vendor is trustworthy, you still have risk from breaches, misconfiguration, and internal access.
3) “Model inversion” and memorization (rare, but not imaginary)
Most major providers work hard to prevent models from spitting out training data verbatim. Still, the risk isn’t zero—especially with smaller models trained carelessly, or when you fine-tune on sensitive text and then expose the model publicly.
4) Third-party tool sprawl
AI features show up everywhere: note apps, CRM add-ons, browser extensions, “smart” keyboards. Each one is another privacy policy, another retention setting, another possible weak link.
5) RAG and embeddings: the new “oops we indexed everything”
Retrieval-Augmented Generation (RAG) is awesome: you embed your docs, search by similarity, feed results to a model. But if you accidentally embed a folder full of confidential junk and store it in a managed vector database with loose permissions… yeah.
Practical rules you can adopt this week
These aren’t perfect. They’re just effective.
Rule 1: Don’t paste secrets into general-purpose chatbots
By “secrets” I mean:
- passwords, API keys, private keys
- full customer records (names + emails + addresses + order history)
- medical info, SSNs, bank details
- unreleased financials, M&A notes, “please don’t share this” decks
If you need help with something that involves sensitive text, redact it first (more on that below) or use a tool designed for private processing.
Rule 2: Use the right mode: consumer vs business vs local
A quick decision tree:
- Consumer AI apps: great for brainstorming, learning, rewriting generic text. Keep it non-sensitive.
- Business/enterprise tiers: often come with stronger controls (no training by default, better admin tools, audit logs, data residency options). Still read the retention policy.
- Local models (running on your laptop or a private server): best when you truly can’t let data leave your environment. You trade some convenience for control.
For NH folks, local can be surprisingly practical now. A decent Mac with Apple silicon or a midrange GPU box can run smaller LLMs for summarization, classification, code help, and internal Q&A.
Rule 3: Minimize data by default
Most AI workflows work fine with less.
Instead of pasting an entire contract, paste:
- the specific clause you’re worried about
- a short description of what you’re trying to negotiate
- only the relevant definitions
Instead of uploading a full dataset, sample it and strip identifiers.
Rule 4: Turn on privacy settings, and verify them
Settings vary, but look for:
- “Do not train on my data” or “model improvement” toggles
- retention controls (30 days, 0 days, etc.)
- admin controls for disabling third-party plugins/tools
- SSO + MFA options
And don’t stop there. If you’re in an org, ask: Can we audit who accessed what? “Trust us” isn’t a control.
A tiny tutorial: redacting sensitive text before using AI
Redaction sounds fancy but you can do a lot with simple patterns.
Option A: Manual redaction (fast, surprisingly reliable)
Before you paste text into an AI tool:
- Replace names with roles:
Jane Doe→[CUSTOMER_1] - Replace addresses with city/state:
123 Main St, Nashua→[NASHUA_NH] - Replace account numbers with placeholders:
ACCT-928182→[ACCT_ID]
Yes it’s tedious. It also works.
Option B: Programmatic redaction (for repeatable workflows)
If you’re a dev or analyst, you can build a quick pre-processor. In Python, for example, you can regex out emails/phone numbers and swap them for tokens. Not perfect, but better than nothing.
Pseudo-ish approach:
- Replace emails:
\b[\w\.-]+@[\w\.-]+\.[a-zA-Z]{2,}\b→[EMAIL] - Replace phone numbers (US): patterns for
xxx-xxx-xxxx,(xxx) xxx-xxxx, etc. - Replace anything matching your customer ID format
Then send only the redacted text to the model.
If you want to get more serious, look at dedicated PII detection tools (open-source and commercial). Just remember: PII detection has false negatives, so treat it as a helper, not a guarantee.
Building private AI systems: the “RAG but don’t leak everything” checklist
A lot of meetup conversations drift toward “we’ll just build an internal chatbot.” Great idea. Here’s where folks slip.
1) Separate public docs from restricted docs
Create clear buckets:
- public marketing docs
- internal but non-sensitive
- restricted (HR, legal, customer data)
Don’t let your ingestion job “just crawl SharePoint/Google Drive and embed it all.” That’s the classic own-goal.
2) Apply access control at retrieval time
It’s not enough to store embeddings privately. You want document-level permissions so the model only sees what the user is allowed to see.
Pattern to aim for:
- user authenticates (SSO)
- retrieval layer filters by user’s permissions
- only allowed chunks go into the prompt
3) Log safely
Logs are where secrets go to hang out forever. Log:
- metadata (doc IDs, latency, error codes)
- minimal prompt traces (or hashed)
Avoid dumping full prompts/responses into a shared logging platform unless you’ve intentionally designed for that and locked it down.
4) Pick vendors like you mean it
Ask direct questions:
- Is data used for training? Default and optional?
- Retention period? Can we set it?
- Subprocessors? Where are they located?
- Encryption at rest and in transit?
- Can we get audit logs?
- What happens if we delete data—real deletion or “soft delete”?
If you can’t get straight answers, that is the answer.
Trends worth watching (because the privacy story is changing)
A few things are shifting under our feet:
- On-device AI is growing fast. More summarization, transcription, and personal assistant features will run locally. That’s a privacy win… when implemented well.
- AI regulation and compliance pressure is increasing. Even if you’re a small NH company, your customers might demand contractual guarantees (DPAs, SOC 2 reports, etc.).
- Synthetic data + differential privacy are getting more practical. Not a magic wand, but they’re real tools for training/analytics without exposing individuals.
- Browser-level and OS-level AI will blur lines. When the OS is doing “helpful” text rewriting everywhere, you’ll need to understand what’s processed locally vs in the cloud.
A realistic privacy posture for most of us
You don’t need paranoia. You need boundaries.
Try this as a baseline:
- Keep sensitive data out of consumer AI tools. Period.
- Use enterprise controls where appropriate: opt-out of training, enforce MFA, restrict plugins.
- Redact and minimize as a habit.
- For internal AI apps, implement permission-aware retrieval and safe logging.
- Write it down: a one-page “AI Use Policy” beats vibes and assumptions.
And yeah, you’ll still make mistakes. We all do. The goal is to make the mistakes small, contained, and fixable.
Bring it to the meetup: what are you using, and what worries you?
At NH AI Meetup, the best conversations usually start with someone admitting “I’m not sure if this is safe.” Same. If you’re building a RAG app, using meeting transcription, experimenting with a local LLM, or trying to get your company on the same page—bring your setup and your questions.
Privacy isn’t the fun part of AI, but it’s the part that keeps the fun from turning into a mess later.