Fernside Studio
Background
Archive
Journal Entry

AI Data Handling: Protecting Sensitive Information

Documented
Capacity
7 MIN READ
Domain
Fernside CMS & Support

When you send client data to an AI API, where does it go? Is it stored? Trained on? Accessible to other users? These aren’t paranoid questions, they’re basic due diligence that most businesses skip. Proper AI data handling isn’t about avoiding AI tools; it’s about knowing what happens to information the moment it leaves your system, and putting guardrails around it before something sensitive gets exposed.

The AI Data Flow: What Happens to Your Inputs

Every time your team pastes text into a chat tool or your website’s AI feature calls a model, the same basic journey happens: your input travels to the provider’s servers, gets processed by the model, generates a response, and, this is the part most people skip past, often gets logged.

Logs are the quiet risk. A provider might not train on your data, but if it’s sitting in a log file for 30 days, that’s still 30 days of exposure to a breach, a subpoena, or an internal access mistake.

The key distinction to understand:

  • Inference: the AI processes your input and returns an answer. This happens every time, and it’s usually where the risk actually lives (temporary storage, logging).
  • Training: the AI provider uses your data to improve future versions of the model. This is what most people worry about, but reputable API providers have moved away from doing this by default.

According to Anthropic’s data retention documentation, standard API log retention dropped from 30 days to 7 days in late 2025, and API data is never used for training. OpenAI’s enterprise privacy page states a similar position: API inputs and outputs may be retained for up to 30 days for abuse monitoring, but are not used for training by default. Both offer Zero Data Retention arrangements for qualifying enterprise use cases, where data isn’t stored after the response is returned at all.

The takeaway: default settings on consumer-facing chat tools (the free version of a chatbot your team might paste client names into) are usually far less protective than the API-level enterprise agreements built for business use.

Provider Data Policies Compared

Not all AI tools are equal, and the gap between “consumer” and “enterprise” tiers is bigger than most founders assume.

Standard/ConsumerEnterprise/API
Training on your dataOften yes, unless opted outNo, by default
Retention periodCan be indefinite (conversation history)7 to 30 days, or zero with ZDR
Human reviewPossible for safety/quality checksLimited, usually abuse-only
Data residency controlRarely offeredSometimes available on enterprise plans

The practical rule: if a tool is free or low-cost and consumer-branded, assume your inputs could be reviewed or used to improve the product unless you’ve explicitly checked the settings and opted out. If you’re building AI into a business process: a website chatbot, an internal workflow, a client-facing feature: use the API or enterprise tier, read the actual data processing agreement, and don’t rely on marketing copy.

The ICO’s guidance on AI and data protection is the reference point for UK businesses here, it sets out that organisations remain accountable for personal data processed through AI systems, regardless of which provider’s model sits underneath. Using a reputable vendor doesn’t transfer your GDPR obligations away, a point we expand on in AI and GDPR.

Data Minimisation in Practice

The simplest protection is the one businesses skip most often: don’t send what you don’t need.

Practical techniques that work without slowing anyone down:

  1. Use reference IDs instead of names: “Client #4471” instead of “Sarah Thompson, 14 Oak Lane.” The AI can still do the task without needing the identity attached.
  2. Redact before you paste: strip emails, phone numbers, and addresses from documents before they go into any AI tool, especially free/consumer ones.
  3. Summarise instead of pasting whole documents: if you only need a tone check or a structure suggestion, send the shape of the content, not the full client file.
  4. Separate the AI task from the sensitive record: ask the AI to draft a template response, then you (a human) merge in the specific client details afterwards.

This is the same discipline as data minimisation more broadly, only collect and process what a task actually requires. It’s not new to AI, but AI makes the temptation to over-share much easier, because pasting a whole document is faster than trimming it.

On-Premise and Private Deployment Options

For most small and medium businesses, cloud API providers with proper enterprise agreements are the right call, the cost and complexity of running models locally rarely makes sense below a certain scale.

That said, there are cases where private deployment matters:

  • Regulated sectors (healthcare, legal, financial services) handling data that legally cannot leave a specific jurisdiction or environment.
  • High-volume, highly sensitive workloads where the cost of a private API instance or VPC deployment is justified by the volume of processing.
  • Contractual requirements from a client or insurer that mandate specific data residency or isolation guarantees.

The trade-off is straightforward: private deployment buys you control, but it costs meaningfully more, both in infrastructure and in the engineering time to maintain it. For the vast majority of UK SMBs, the better first step is choosing providers with strong zero-retention options and building good internal habits, not standing up your own model infrastructure.

Building a Data Handling Policy for AI

Most businesses using AI tools have no written policy at all, decisions happen ad hoc, tool by tool, person by person. A short, practical policy closes that gap without needing a legal department.

A working template covers:

  • Data classification: define four tiers: public, internal, confidential, restricted. State plainly which tiers are approved for AI processing and which are never allowed near an AI tool (client financial records, health data, and similar should sit in “restricted, never”).
  • Approved providers: name the specific tools your team can use, and specify enterprise/API tier only, not consumer sign-ups.
  • Required redaction: spell out what must be stripped before any confidential-tier data goes into an approved tool.
  • Approval process: who signs off when someone wants to use AI for a new task involving customer data. One person, clearly named, beats a committee nobody consults.
  • Review cadence: revisit the policy every 6 months; provider terms change often enough that a stale policy becomes wrong quietly.

This doesn’t need to be a 20-page document. A single page that a new hire can read in five minutes is more useful than a comprehensive policy nobody follows.

Where This Fits Into Your Website and Systems

If your website includes an AI chatbot, an automated enquiry handler, or any feature that processes visitor or client information, the same principles apply to what you’ve built, not just the tools your team uses day to day. A poorly configured CTA-driven contact flow that quietly logs every enquiry through a consumer AI tool creates exactly the exposure this article is warning about.

At Fernside Studio, when we build AI systems into a client’s site or internal workflow, data handling is part of the build, not an afterthought bolted on later. That means choosing providers with proper enterprise agreements, minimising what gets sent to any model, and being explicit with clients about what’s stored and for how long. If you want a second opinion on how your current AI setup handles data, our advisory sessions are built for exactly that kind of review.

Sources

Handling sensitive data through AI systems responsibly isn’t optional, it’s the baseline. If you’re building or reviewing AI features on your website, get in touch and we’ll help you scope it properly.