Most small teams do not need a grand AI policy before they try useful tools. They need AI data classes: a plain way to decide what information can be shared, what needs a protected route, and what should stay out of an AI workflow altogether. That small design choice turns privacy from a late-stage legal scramble into a product decision people can actually follow.
Table of Contents
The question is not cloud or local
The first debate around a new assistant is often framed as a technology choice: cloud model or local model? That matters, but it arrives too early. The useful first question is: what kind of information is this?
A public product description and an unannounced pricing exception should not automatically travel through the same route. A visitor asking for opening hours is different from a customer pasting a contract, a health detail, or a staff performance note. If every input is treated alike, the team has quietly made a privacy decision without naming it.
This is why AI data classes are more useful than a blanket rule such as “never use cloud AI” or “put everything into the chatbot.” They let a business set a route that fits the information and the job. That route may use a hosted model, a local model, a retrieval system, a human queue, or no automation at all.
The NIST AI Risk Management Framework is voluntary, but its core habit is valuable at any size: build trustworthiness considerations into how systems are designed, used, and evaluated. Classification gives that habit an everyday interface.
Start with four AI data classes
Do not begin with twenty labels. Start with four, write them in normal language, and give each one an owner.
- Public: information already intended for anyone to see, such as approved website copy, published FAQs, and public product documentation.
- Internal: working material that can help an assistant but is not for public release, such as draft campaigns or internal process notes.
- Restricted: customer, commercial, or operational information that needs approved tools, narrower access, and a recorded purpose.
- Do not process: information that should not enter the workflow at all without a specific human decision, such as credentials, payment details, or sensitive personal information.
The names can change. The point is that AI data classes describe the business consequence, not an abstract security score. A receptionist, marketer, developer, and founder should all be able to place an example in a class without consulting a spreadsheet full of acronyms.
This also complements named stewardship for AI sources. Source stewardship asks who owns the truth an assistant may use. Data classification asks where that information may go and what the system may do with it. Both questions belong in the same implementation conversation.
Make the route visible
A class only changes behaviour when it triggers a route. Put that route somewhere a product team can see: in the workflow canvas, the integration setup, the support playbook, or the product brief.
For example, a meLink web assistant might answer a public visitor question from approved website content. If the conversation turns into a request for account-specific help, it can collect only the minimum contact details, explain the next step, and hand the case to a person. It should not improvise access to an internal system just because the user sounds urgent.
For restricted work, the route can require an approved provider, a limited retention setting, a private retrieval store, or a local inference step. Model portability becomes practical here: a well-defined route lets a team change the model beneath it without silently changing the information boundary.
The UK Information Commissioner’s Office provides AI and data-protection guidance for organisations assessing these responsibilities. It is not a substitute for legal advice, but it is a useful reminder that an AI feature is also a data-handling design.
Test the boundaries before the demo
Good AI data classes are tested with uncomfortable examples, not just a tidy diagram. Ask the team what happens when a visitor uploads an invoice, when a colleague pastes a customer complaint into a general-purpose tool, or when an agent is asked to summarise a private meeting.
For each case, make four answers explicit: which class applies; which route is allowed; what must be removed or masked first; and when a human must take over. This is a small version of a risk review, but it catches the costly ambiguity before it becomes a customer incident.
It also creates better product tests. Rather than asking only whether the assistant gives a fluent answer, test whether it refuses the wrong input, takes the approved route, explains the limit clearly, and leaves a useful handoff. Those checks make “privacy-respecting” observable instead of decorative.
Classification is a growth tool
It is tempting to see classification as the brake pedal. In practice, it can be the map. When a team knows its AI data classes, it can say yes to low-risk automation faster, invest in a stronger route where the value is real, and decline work that needs more trust than the current product can earn.
That is a stronger promise to customers and investors than “we use the latest model.” It says the business knows what its AI is for, what information it deserves, and where people remain in charge.
Privacy is not the wall around an AI product. It is the set of doors that lets the right work move safely.
Leave a Reply