Hanad KubatVisit Website →
← Back to blog

AI Privacy for Clients: How to Protect Their Data

November 1, 2026
AI Privacy for Clients: How to Protect Their Data

AI privacy for clients comes down to one question: where does your client's information go once it touches an AI tool, and who can keep, read or reuse it there? If you cannot answer that for every tool in your business, you have a privacy gap. This guide shows how to find it, what to ask vendors, and how to build or buy AI features that keep client data under your control.

I am Hanad Kubat, a senior software engineer in Vienna. I build AI features and first versions of software for founders and owner-operated businesses, so the advice below comes from the build side as much as the policy side.

Hanad Kubat
Build AI Features With Privacy in Mind
Hanad Kubat builds AI features and working software versions for founders and owner-operated businesses, with the client owning the code from the first commit.
Visit Hanad Kubat

Key Takeaways

  • Treat anything a client tells you as sensitive by default. Pasting it into a public AI tool can hand it to a third party.
  • Provider terms decide what happens to prompts, uploaded files and outputs. Read them before the first client record goes in.
  • The strongest protection is not sending personal data to the model at all. Minimize, redact or anonymize first.
  • A short written policy, a vendor checklist and access controls on logs cover most of the real-world risk.
  • Contracts matter: if you outsource AI development or processing, you still answer for the data.

Table of Contents

What AI privacy means for client information

AI privacy is the practice of protecting personal or sensitive information that an AI system collects, uses, shares or stores. For a business, that includes what your staff type into a chatbot, what you upload for summarizing, and what an AI feature in your own product sends to a model behind the scenes.

The Australian privacy regulator states the principle plainly: personal information that you enter into an AI system, or that the system generates, remains subject to data protection obligations, so it must be handled lawfully and transparently. Collection has to be necessary and respect the rights of the people involved, as set out in the OAIC guidance on commercially available AI products.

Two points are easy to miss:

  • Removing names is not always enough. The UK Information Commissioner's Office notes that data can still count as personal if it lets someone be singled out, even when direct identifiers are gone. See the ICO guidance on individual rights in AI systems.
  • Output counts too. What the model generates about a client is client data. It needs the same care as the input.

Where client data leaks when you use AI

Most leaks are not hacks. They are ordinary decisions made quickly: a staff member pastes a contract into a chatbot to get a summary, or a developer wires an AI feature to a model without checking where the data goes.

Public tools and lost visibility

The ICAEW warns that when businesses put client data into tools like ChatGPT, they have limited visibility and control over how it is shared, secured and retained, which can breach confidentiality. Its note, Don't let AI tools land you in hot water, also reminds users to stay skeptical of outputs, since models can invent references and sources.

The American Bar Association makes the same point for lawyers: AI tools often run on cloud platforms that send inputs to external servers, so a conversational interface should not be assumed private. The ABA authors frame this as the key difference from traditional software: the data leaves your controlled environment to be processed elsewhere.

Reuse by the provider

The Cyber Readiness Institute advises that public generative AI tools can store, process or reuse what you enter, which may expose proprietary business data. Its guide to secure GenAI use suggests a simple habit: when in doubt, assume the data is sensitive.

Privilege and professional duty

For lawyers and similar professions the stakes are higher. A US law firm advisory explains that pasting confidential information into a public or unvetted tool can disclose it to an unauthorized third party if the vendor's terms allow training or retention without comparable confidentiality commitments, and that disclosure outside the privileged relationship may waive privilege. The authors stress that such a waiver is typically irreversible. If you are a doctor, lawyer, accountant or other professional, check your own regulator's rules as well as the vendor's terms.

What AI providers do with your data

Providers differ, and the differences are in the terms, not the marketing. The New South Wales Information and Privacy Commission warns that some providers use customer prompts, uploaded files and model outputs as training data to improve their systems, which creates privacy exposure. Its guide to privacy risks of generative AI tools recommends assessing vendors' privacy controls, contractual safeguards and data flows.

In practice, for each AI tool or API you use, you want written answers to six questions:

QuestionWhat a good answer looks like
Is my data used to train models?No, by default and in the contract
How long is data retained?A stated period, ideally short or configurable
Can I delete it, and how?A documented deletion route with a timeline
Who are the subprocessors?A named list, with notice of changes
Where is data processed?A stated region that fits your obligations
What security controls apply?Encryption, access control, audit logging, named certifications

The Cyber Readiness Institute's guide lists the same themes for founders: data use, retention and deletion, subprocessors and security controls. If a vendor cannot answer in writing, that is your answer.

For a deeper process, my article on running an AI vendor risk assessment walks through scoring vendors. If you operate in or sell into Europe, five vendor questions on EU data residency cover where processing really happens.

Public AI versus private AI

A Maryland accounting and advisory firm draws a useful line. Public AI systems are open to anyone and may use inputs to train the model. Private AI is developed and deployed inside an organization's infrastructure, is trained on its data, and generally stays under its control. That distinction is laid out in this overview of AI and client confidentiality. The same piece observes that fully private setups are often too costly for small and medium-sized businesses.

That cost point is worth taking seriously, but it is not a binary choice. Between a free public chatbot and a fully private model there is a middle path that most small businesses can afford:

  1. Business-grade access to a model through an API or enterprise plan, with contractual terms on training, retention and deletion.
  2. Your own application in front of the model, so you decide what is sent, what is logged and who can see it.
  3. Data minimization before the call, so personal details never reach the provider.

The third step does most of the work. If the model never sees the client's name, address or case details, the provider's retention policy matters far less.

Rules vary by country and sector, so treat this as a map, not legal advice. Talk to a privacy lawyer in your jurisdiction for your specific case.

  • Outsourcing does not move responsibility. The European Data Protection Supervisor's guidance says that when an EU institution outsources development of a generative AI model, it remains the controller and a data processing agreement must be in place. See the EDPS revised orientations on generative AI. The same logic is a sound habit for any business: the vendor processes, you remain accountable.
  • Put expectations in the contract. The UK ICO advises including accuracy-based KPIs or SLAs in written contracts with third-party AI suppliers, and expects due diligence to include checks for bias and discrimination before procurement. Both points are in its guidance on contracts and third parties.
  • Hold AI suppliers to your normal security standard. The UK National Cyber Security Centre says organizations should require AI suppliers to meet the same security standards as other software components, in its guidelines for secure AI system development.

If your clients are in the EU, GDPR applies to personal data you process for them regardless of where you sit. I cover that in GDPR for AI: closing high-risk gaps, and for high-risk processing there is a copyable AI DPIA template. The AI-specific rules are summarized in a practical EU AI Act checklist for founders.

A practical checklist before client data touches AI

This is the order I would work through in an owner-operated business. It takes days, not months.

  1. List every AI tool in use. Include the ones staff signed up for on their own. You cannot protect what you have not found.
  2. Sort them into public and approved. Public tools get no client data. Approved tools have reviewed terms.
  3. Write a one-page policy. Say what may never be entered (client names, case details, financial records, health data) and what may, for example anonymized text.
  4. Run the vendor questions from the table above and keep the answers on file.
  5. Minimize before sending. Strip or replace identifiers, and send only the fields the task needs.
  6. Restrict access. Only the people who need an AI feature should have it, with the minimum permissions.
  7. Protect the logs. The UK NCSC advises treating AI logs as sensitive data with strong access controls, because prompts and outputs often contain exactly what you were trying to protect.
  8. Train staff and review regularly. The Cyber Readiness Institute stresses that governance, meaning active oversight and not just a list of banned tools, is what makes generative AI use secure.
  9. Check outputs before they reach a client. Hallucinated facts are a quality problem and, with personal data, can become a privacy problem too.

If you want a structured way to run steps 1 to 4, an AI audit checklist your team can actually run is the version I use.

Building AI features that keep client data private

If you are putting AI inside your own product, privacy is an architecture decision, not a settings page. A few design choices make the difference.

Keep raw personal data out of prompts

A redaction layer sits between your app and the model. It detects personal details, swaps them for placeholders, sends the safe version, and restores the values in the response on your side. I describe an approach in shipping an MVP that keeps raw PII out of prompts. Combined with the principle of collecting less in the first place, covered in five steps for GDPR data minimization in MVPs, this removes most of the exposure at the source.

Redact, send, and restore personal data safely

Document what you build

The NCSC recommends documenting the creation, operation and life cycle of models and datasets, including training data sources and retention times, using tools such as model cards. For a small product, that can be a single page per AI feature: what model, what data goes in, what is stored, for how long, who can see it.

Roll out in stages

Start with a narrow feature, a small set of users and test data. Widen only after logging, deletion and access control work as designed. A phased plan for shipping AI features safely and five guardrails for SaaS founders lay out the stages.

Plan for deletion

A client asks you to delete their data. Can you remove it from your database, your logs, your vector store and any provider-side storage? Design for that answer on day one. Retrofitting deletion across a tangle of services is expensive.

Perspective

Most privacy problems I see in AI projects are not exotic. A founder or a team lead wires up a model quickly, client data flows through places nobody mapped, and months later someone asks where it all went and nobody can say.

I build these systems myself, end to end, so I know where the data goes because I wrote the path. That is the practical advantage of working with one senior engineer: no layers of hand-offs where responsibility gets lost, and no surprises in the architecture.

My approach is deliberately plain. Redact before the model call, log carefully, use boring and widely known tools like TypeScript, Next.js, Node and SQL, and document the data flow so the next developer can read it. You own the code from the first commit, so you are never locked into my choices or a platform's terms.

If an off-the-shelf tool with a proper business agreement fits your case, I will tell you so. Custom software is the right answer when your client data is the product, or when no existing tool lets you control where it goes.

Hanad Kubat

Work with me on a privacy-first build

If you want an AI feature, a first working version of a product, or an internal tool that handles client information, I build it at a fixed price and a fixed scope, usually in two to four weeks. Your app projects start from €12,000, and websites from €3,500. You see working progress before you pay, and you own the code from the first commit. Tell me what client data is involved and I will tell you honestly how I would keep it under your control.

FAQ

Is it safe to put client information into ChatGPT or similar tools?

Not by default. Public tools can store, process or reuse what you enter, and you have limited visibility into how it is retained. Use a business-grade plan with contract terms on training and retention, or remove identifying details before you paste anything.

What is the difference between public and private AI?

Public AI is open to anyone and may use inputs to train its models. Private AI runs inside an organization's own infrastructure and generally stays under its control. Between the two, an application of your own that calls a model under business terms, with data minimized first, is a realistic option for most small businesses.

Does anonymizing client data make it safe to use with AI?

It helps a great deal, but only if it is done properly. Data can still count as personal if it lets someone be singled out, even without names. Send only what the task needs, and have your privacy adviser confirm that your anonymization really works.

What should I ask an AI vendor before sharing client data?

Ask whether your data is used for training, how long it is kept, how it can be deleted, who the subprocessors are, where it is processed and what security controls apply. Get the answers in writing and in the contract. If you outsource AI development, make sure a data processing agreement is in place.

Do I need a written AI policy for a small business?

Yes, and one page is enough to start. It should say which tools are approved, what data may never be entered, who can use AI features and who reviews the setup. Governance, not just a list of banned tools, is what keeps use secure over time.

Sources