Client data and AI: a simple data classification policy

Start with a classification policy, not a rulebook

Most teams do not need a 20-page acceptable use policy to make better decisions about client data and artificial intelligence (AI). They need a one-page data classification policy that answers one question at the moment they are about to paste: which category is this information in? A concise schema of three to five levels is easier to apply consistently, and three levels cover the decisions most firms face (sentinelone.com). AI systems rely on large data sets for training and decision-making, which is why classification matters more now than it did for older tools (trustcloud.ai). The point is not to create another rulebook. The point is to make the default classification visible.

Define the restricted category first

Restricted means stop and do not paste into a public AI tool without explicit review. This category includes anything that identifies a client, such as names, addresses, account numbers, or matter details. It includes financial records, protected health information (PHI), contracts under confidentiality terms, and any data protected by law or professional ethics rules. Treat internal strategic plans and pre-release financials as restricted too.

Different readers will see this list through their own daily work. A dental or medical practice should treat patient charts, scheduling records, and billing details as restricted. An accounting firm should treat tax returns and workpapers that way. A nonprofit should treat donor records, grant applications, and board minutes as restricted. A small company should treat source code, pricing, and vendor terms as restricted. For any regulated or client data, the safe answer to "can I paste this?" is rarely yes.

If your organization has an approved enterprise AI tool with contractual protections and data isolation, some restricted items may move to internal, but only after a named owner reviews the tool and the specific data. A blanket ban is hard to enforce and can push people toward unofficial tools. A better approach is approved tools, redaction requirements, and an audit trail.

What enterprise AI tools need in writing

Before you move anything restricted into an AI tool, distinguish a shared consumer tool from an enterprise or private deployment. In a shared tool, prompts, uploads, and outputs may become part of the vendor's model training data unless the contract says otherwise. An enterprise tool should be isolated to your organization and contractually barred from using your data for model training or any other reuse.

The contract terms to look for include: no training on your data, no reuse, retention and deletion windows, a list of subprocessors, and an incident notice period. The policy should cover the full AI data surface: prompts, uploaded files, retrieved context, generated outputs, system logs, evaluation data, and fine-tuning data (prismocode.io). Pay special attention to logs. Full prompt capture can help with support, but it creates another store of sensitive data, so retention limits, masking, and reader access need hard limits (prismocode.io).

This is part of broader data governance work, but the immediate step is contractual clarity. Because exact legal duties vary by practice area and location, Jecovia works alongside your attorney when you classify regulated data.

Identify internal data that needs a check

Internal means pause and check before pasting. Examples include drafts with client names removed, aggregate counts like "we served 47 clients this quarter," and internal templates that do not contain client identifiers. Sources anyone can look up, such as published court rulings or regulatory filings, are not confidential on their own, but they belong in this tier when they appear next to client context that could point back to a specific matter. Internal is not an automatic yes. A de-identified draft can still be re-identified if it includes enough context, such as a niche industry and a recent transaction.

A single rule covers most of this: if the original version would be restricted, remove every identifier and ask the named owner to confirm it is safe for the specific tool. If that confirmation takes more than a minute, keep it restricted for now. The same applies across sectors: a dental practice's de-identified scheduling block or a nonprofit's donor counts without names still deserve a quick check if the remaining details could point to an individual.

Classification also shifts as you combine elements. Two separate internal items might be fine on their own, but together they can identify a client or reveal a confidential matter. For example, a count of 47 clients is internal; pairing it with the firm's specialty and a recent transaction could re-identify someone. Ask whether the combined set crosses a line before pasting.

Allow public and generic information by default

Public means go ahead. This includes generic prompts like "write a polite follow-up email for an overdue invoice," public information that anyone could find on a website, and your own non-confidential work such as first drafts of public marketing copy or brainstorming for an internal newsletter. Public items do not require a pre-check, but they should still follow the firm's general professional standards.

Add controls for each level

Classification is meaningless without handling rules. Restricted data stays in approved systems only, with encryption, data masking where useful, role-based access limited to named staff, and data loss prevention (sentinelone.com). Internal data may go into an approved tool after identifiers are removed and the named owner confirms. Public data needs no gate. Train staff on these boundaries and set a no-blame expectation for reporting accidental pastes, because a quiet mistake can grow into a bigger exposure (sentinelone.com). These controls sit inside your security program.

Put one person in charge of borderline classifications

A data classification policy fails when every borderline case becomes a hallway debate. Name one person, perhaps an office manager, practice administrator, or CFO, who owns gray-area decisions. That person does not need to be technical. They need to know the client base, the contractual promises the firm has made, and the risk tolerance of the partners. Their job is to answer "Is this internal or restricted?" within a few minutes, and to write down the decision so the policy gets more accurate over time. An effective classification policy also includes an audit trail, so past decisions can be looked up and applied the same way next time.

Keep the classification policy posted where people paste

A policy in a shared drive does not help at 5 p.m. when someone is rushing to draft a client email. Print the one-page classification guide and post it at desks, on the wall above the printer, or in the team chat where people share AI prompts. If staff work remotely, pin it in the channel where AI questions come up. Make it easy to read, with three clear categories and short lists. If it cannot be read in ten seconds, it is too long.

Review the policy quarterly as AI tools change

AI tools change defaults, add new tiers, and update how they handle data. A classification that was accurate in January may be wrong by April. Schedule a 30-minute review every quarter with the named owner and two or three frequent AI users. Ask four questions: Are people using any new tools? Did any restricted data accidentally get pasted? Did any internal item cause confusion? Have client contracts or professional rules changed what counts as confidential? Update the one-page policy accordingly. Also revisit the contractual terms from the enterprise tool section: data processing agreements, security riders, and statements of work should still match how the vendor actually handles data, and the technical controls should match those promises. Jecovia can help with vendor management when you need that assessment.

If it cannot be read in ten seconds, it is too long.