10.2 Can this data go in?

In everyday life. A friend asks to borrow your car for a day. You give them the car key, not your house keys and your bank card. The task needs one key.

What you will learn. How to decide what data a task needs before it goes to an AI tool, and how to remove the rest without breaking the task. You practice it in step 2 of the lab.

Why it matters. Data you never sent cannot leak, and most tasks need less than the whole file.

A reasonable task can still use data that should not go into an AI tool. Decide in this order:

1. Classify the data. This book uses three tiers, or levels. Translate them into your organization's labels. Never replace your organization's labels with them.
   • Green: public material, and internal material clearly approved for broad use. A total is not green just because it is a total. A month's total of payables, the bills a company owes, can be as confidential as the rows behind it.
   • Yellow: check first or add a control, a setting or step that limits what can happen to the data. Examples are internal-only documents, customer or vendor contact details, employee identifiers and confidential drafts.
   • Red: only through a route approved for this kind of data. A route is the way data reaches an AI tool (10.3). Examples are passwords and access keys, bank account numbers, government ID numbers, health records, privileged legal advice, and material whose license forbids copying it elsewhere.
2. Ask whether the task needs the identifiers, or only the pattern. Identifiers point to one exact person or vendor. Spending trends need the pattern. Paying one vendor needs the account number.
3. Confirm the route, and what the data may be used for (10.3).
4. Choose the control.

If you are unsure between two tiers, use the higher one, nearer red, until someone who owns the policy says otherwise.¹ Some kinds of data are covered by special rules. In the United States, Social Security numbers, health information and payment card numbers each have their own rules, set by law or by contract. Chapter 32 names the main sets of rules. For you, the rule is simpler. If you do not know which rule applies, treat the data as red and ask.

Maria, the office manager at Brightline, the book's example company, had to find duplicate vendors in the company's vendor file, before the year-end tax forms. Duplicates appear in names and addresses, and in matching tax ID numbers. The task did not need bank account numbers at all. It did not need full tax IDs either. In this file, the type of tax ID and its last four digits, together with names and addresses, mark likely matches for a person to confirm. A match is a candidate, a possible duplicate, not proof. A larger file may need more fields.

Removing the fields a task does not need is redaction. Redaction can fail in two ways. It can leave enough clues to identify someone, such as an unusual name with an exact address. Or it can remove what the task needed, so the result looks safe and finds nothing.¹ Check a redacted file against a few answers you already know before you trust it.² And a redacted file is safer, not safe. A redacted copy of Maria's file still holds the names and addresses of sole proprietors, people who each run a business on their own. So it drops from red to yellow, and it still needs a route approved for yellow data.

Replacing names with labels such as "Vendor 17" is not enough. If someone still holds the list that links the labels back to names, the data is pseudonymized, not anonymous, and it keeps its tier.

Data also arrives with a purpose: the reason it was collected. Brightline collected contractors' tax IDs to file tax forms. Using them to train an outside company's AI model was never part of that purpose. When a new use is outside the purpose, the person who owns the data decides.¹

Figure 10.2. Can this data go in? The panel on the right applies it to Maria's vendor clean-up.