It is 4:40 on a Thursday afternoon and the analyst two desks over from you has a good idea. She has been staring at the invoice-exception backlog all week, she has a customer export open in one window and a personal chatbot account open in the other, and the thought forming in her head is the most natural thought in modern office life: "let me just paste a chunk of this in and see if it can categorize them." No malice. No scheme. Just momentum, a deadline, and a tool that is right there. In the next lesson of this story, one of two things happens. Either someone has already run a half-day exercise called the Data Pre-Flight Checklist, and she knows exactly which sanctioned tool to open and which nine columns get masked first, or she pastes, it works beautifully, the idea ships upward as a pilot proposal, and four months later a security review asks one quiet question that freezes the pilot, disciplines the analyst, and puts every future AI proposal from her department through a three-week review. This lesson is about making the first version of Thursday afternoon the only version that can happen.

The Lane That Does Not Negotiate

Everything else you have done in this audit chapter has been negotiable by triage. A stale data source can be refreshed or worked around. A missing field can be estimated with a documented caveat. A quality gap costs you time, money, and sometimes the pilot itself, and last lesson you learned to sort those gaps into fix-now, fix-later, and design-around. That sorting logic is the heart of an assessor's craft, and this lesson exists to tell you where it stops.

Privacy, security, and access are not a triage lane. They are a wall. A quality gap, discovered late, costs the pilot. A privacy or security violation, discovered late, costs careers, triggers regulators, damages customer trust, and can put contractual penalties on the table that dwarf the pilot's entire budget. The asymmetry is total: on one side of the wall the worst case is a delayed project, on the other side the worst case has a legal department, a communications plan, and sometimes a press cycle attached to it.

Here is the part that makes this a process lesson rather than a scare story: these violations are almost never committed by bad people. They are committed by momentum. The well-meaning analyst under deadline. The manager who forwards a sample "just so you can see the format." The consultant who uploads a contract to a summarizer because the meeting is in an hour. In Level 1 you met this pattern as shadow AI, the unsanctioned personal-account usage that happens in every organization whether leadership admits it or not. What changes in Level 2 is the payload. Shadow AI with a draft email is a policy question. Shadow AI with a customer export is an incident.

Your job as the assessor is not to police anyone and it is emphatically not to play lawyer. Your job is to make the safe path explicit, visible, and easy before the pilot creates the pressure to cut corners. Pressure always wins against an invisible rule. It usually loses against a checklist that was run in week one, signed by named owners, and pinned to the front of the audit file. One framing sentence governs everything in this lesson: the assessor flags, counsel decides. You will learn to spot five families of flags and route each one to the person entitled to make the call. You will never be asked to reach a legal conclusion, and you should refuse to reach one even when the room wants you to, because "the process person said it was fine" is a sentence that protects nobody, including the process person.

The clock behind this is real and dated, which is exactly how Level 1 taught you to treat governance. The EU AI Act's obligations for general-purpose AI (GPAI, the broad foundation models behind most of the tools you will pilot) have been live since August 2, 2025. Transparency obligations for AI-generated content arrive December 2, 2026. High-risk system obligations follow on December 2, 2027 for the Annex III categories and August 2, 2028 for AI embedded in regulated products, under the post-Digital-Omnibus calendar. But do not let the AI calendar hypnotize you, because the sharper point is simpler: data-protection law already applies today, everywhere you operate, regardless of whether AI is involved. Pasting personal data into an unauthorized system was a violation before chatbots existed. The chatbot just made it feel casual. Regulated industries and specific jurisdictions add their own layers on top, which is one more reason your output is a routed flag, not a verdict. Nothing in this lesson is legal advice; all of it is the operational discipline that makes the legal questions answerable.

The Artifact: The Data Pre-Flight Checklist

The named artifact of this lesson is the Data Pre-Flight Checklist, and its rule of engagement is absolute: it runs per data element, before any sample, export, or byte reaches any model or vendor. Not after the first promising experiment. Not in parallel with the pilot's week one. Before. The name is deliberate. A pilot does not taxi to the runway while someone is still checking whether the fuel is flammable; the check happens on the ground, when finding a problem costs a walk back to the hangar instead of an emergency.

The checklist asks five questions of every row in your Process Data Register, the inventory you built earlier in this chapter:

• What is in it? Field by field, does this element contain anything that identifies a person, anything a contract restricts, anything the business classifies as confidential?
• Who may see it? Which roles, which teams, which external parties are entitled to view this data, and does that set include the AI vendor?
• Where may it travel? Which systems, which tenants, which countries may hold a copy, and does the pilot's tooling stay inside that boundary?
• How long may it live? What retention applies to the original, and what retention will apply to every copy the pilot creates in prompts, logs, and exports?
• Who signed? Which named human authorized this element for this specific purpose, and where is that authorization written down?

Every run of the checklist produces one of four outputs per element, and the fourth is the one that makes it a governance instrument rather than a form: cleared (use as is, with the sign-off recorded), cleared with conditions (usually redaction or masking before anything leaves the source system), blocked pending authorization (the data owner has not signed, so nothing moves), or routed to the legal or privacy owner (a question the assessor is not entitled to answer has surfaced, and it now belongs to someone who is). That fourth output is written on the checklist explicitly because an escalation path that exists only in people's heads is an escalation path that loses to a deadline.

No byte reaches any model until the pre-flight says what is in it, who may see it, where it may travel, how long it may live, and who signed.

Notice what the checklist is doing psychologically. It is not adding friction to the fast path; it is building the fast path. Once an element is cleared, everyone downstream can move at full speed with no anxiety and no whispered "are we allowed to use this?" in week six. The half day you spend running it is the cheapest insurance the pilot will ever buy, and it becomes the pilot's first governance artifact: the document you will cite in next lesson's readiness report and the seed of the full governance program you will build in Level 4.

The Five Flag Families

The checklist's five questions work because behind them sit five families of flags. Learn to recognize the families and the questions ask themselves. Each family below comes with the scene where it typically appears, the flag question you raise, and the owner it routes to.

1. PII and Special Categories

PII is personally identifiable information, and the plain definition is the useful one: anything that identifies a person, directly or in combination. Names, email addresses, phone numbers, bank details, employee IDs, and also the sneakier combinations: a job title plus a department plus a start date identifies one human in most companies just as surely as a name does. Special categories (health, beliefs, biometrics, and similar) carry stricter rules almost everywhere and should be treated as an automatic route-to-privacy-owner, full stop.

The scene: you pull a sample of invoice exceptions for the pilot, and the sample is soaked in PII you stopped seeing years ago. Vendor contact names. Their direct phone numbers. Bank account and routing numbers on every remittance line. The approver's name on every workflow step. Familiarity is the enemy here; the data does not feel sensitive because you have scrolled past it ten thousand times.

The flag question: does the pilot need identity, or does it need the pattern? Almost always, it needs the pattern. A model learning to categorize invoice exceptions needs to know that a mismatch occurred between a purchase order and an invoice amount; it gains nothing from knowing that the vendor contact is named Marta Kovacs and banks at a particular institution. Which introduces the default move of this whole family: strip identity before anything moves. Redaction is removing or blanking the identifying fields entirely. Pseudonymization is replacing them with consistent stand-ins (VENDOR_017, APPROVER_C) so the structure survives for analysis while the identity does not. You met "mask before sampling" as a habit in the data inventory lesson; the pre-flight formalizes it into a recorded condition with a named signer. Route to: the privacy owner for anything you are unsure about, and always for special categories.

2. Confidentiality and Contract Boundaries

The second family has nothing to do with individuals and everything to do with promises. Customer contracts contain data-handling clauses. Nondisclosure agreements (NDAs) restrict what may be shown to whom. Supplier agreements routinely forbid sharing pricing with third parties. Your organization signed those promises, often years ago, often in clauses nobody in operations has ever read.

The scene: a procurement pilot wants to analyze supplier quotes. Someone asks, reasonably, whether the supplier would mind. Someone else says the magic words, "it's just going to the AI, not to a person." And here is the fact that surprises people in exactly the meetings where the surprise is expensive: the model vendor is a third party. Contractually, sending supplier pricing to an AI vendor's system is sharing it with a third party, the same as emailing it to a rival would be in the clause's eyes, unless the contract says otherwise. The tool's friendliness does not change its legal position.

The flag question: whose data is this really, and what did we promise them? You are not expected to answer it. You are expected to notice that it exists, pull the contract reference into the checklist, and route it to legal or the contract owner. In the worked example below, this route takes eight days to come back. Eight days in week one is a rounding error. The same eight days discovered in month four, with the pilot built on top of the assumption, is a stopped pilot.

3. Tool and Tenancy Boundaries

The third family is about where the prompt goes. In Level 1's vendor-diligence work you learned to ask three questions of any AI tool: where does the prompt travel, is it retained, and is it used for training? Now aim those questions at your own daily behavior, because the gap between an enterprise AI tenant and a personal account is the gap between a controlled environment and the open internet wearing a friendly interface.

An enterprise tenant is your organization's contracted, configured instance of an AI service: access is tied to company identity, retention is set by contract, training on your data is typically excluded in writing, and logs exist so that questions asked later can be answered. A personal account is a consumer product governed by consumer terms that your organization never negotiated and cannot see into. Same underlying model, unrecognizably different data position.

The scene is the one this lesson opened with, and the flag is not subtle: any work data in any tool the organization has not sanctioned is a reportable event, not a productivity hack. That sentence deserves to be quoted verbatim in your audit file, because it draws the line where people most want it blurry. The pre-flight's tenancy check is mechanical: confirm the sanctioned-tool list exists, confirm the pilot's tooling is on it, and record the tenant's retention and training terms in one paragraph. Route to: the security or IT owner, who maintains the sanctioned list, and who would much rather approve a tool in week one than investigate one in month four.

4. Retention and Deletion

The fourth family asks the question data always outlives: how long may this live? Not just the original record in the source system, which probably has a retention policy already, but every copy the pilot will spawn. The prompt sent to the model. The vendor-side log of that prompt. The exported sample on a laptop. The "temp" folder that is never temporary. The spreadsheet attached to a status email.

The pre-flight makes this concrete with one unglamorous question: where will every copy of this sample exist in 90 days? If the answer is a shrug, the flag is raised. The classic audit finding in this family is almost comically mundane: the forgotten CSV of customer data sitting on a desktop eighteen months after the pilot it served was cancelled, discovered by exactly the kind of review you do not want discovering things. The scene has no villain, only entropy. The fix costs nothing at pre-flight time: name where samples may live, set a deletion date, name who deletes, and write all three on the checklist. Route to: the data owner and security owner jointly, since one owns the policy and the other owns the enforcement.

5. Access and Authorization

The fifth family draws the finest distinction of the five, and the one that most reliably separates trained assessors from enthusiastic amateurs: the difference between "I can open this table" and "I am authorized to use it for this purpose." The first is a fact about your system permissions. The second is a fact about governance. In privacy language this is purpose limitation; in plain words, data collected to pay invoices was authorized for paying invoices, and feeding it to an AI pilot is a new purpose that needs its own yes from someone entitled to give it.

The scene: the pilot team discovers the assessor already has read access to the payments table, and the room relaxes, because surely access equals permission. It does not. Access is plumbing; authorization is a decision. The flag question routes to the data owner: "we intend to use elements X and Y for pilot purpose Z, sampled and masked as follows, retained until this date. Do you authorize this use?" And here is a satisfying piece of thrift: the timed access request you learned in the gap lesson, where you formally request access and measure how long the organization takes to grant it, doubles as the authorization test. One email produces two audit findings: whether the purpose gets a yes, and how long the machinery takes to say it. Route to: the data owner, always, in writing.

Five families, five questions, five owners. Notice that not one of the routes ends at you. That is the design. The assessor's authority in this lane comes precisely from not claiming authority: you are the person who made sure every question reached someone entitled to answer it, in week one, in writing.

Where AI Helps, and the One Place It Absolutely Must Not

It would be a strange lesson in an AI-assisted auditing chapter that banned the assistant, and this one does not. AI is genuinely useful in three pre-flight tasks, provided you hold the verification habit you built in Level 1: every AI-touched claim gets checked by a human before it is acted on.

Drafting the checklist run. Paste a register row's field list, the schema, never the data, into your sanctioned tool and ask: "which of these fields could identify a person directly, and which combinations could identify someone indirectly?" The model is good at the combinatorial paranoia humans skip. It will notice that department plus hire month plus job grade is a fingerprint. You then verify its list against the actual fields, because it will also occasionally invent a column that does not exist, and you learned in the verification lessons what to do about confident inventions.

Second-pair-of-eyes on a redacted sample. After your redaction script runs, paste a small, already-masked sample into the sanctioned tenant and ask it to hunt for missed identifiers. This is the ideal AI task: the downside of a false positive is thirty seconds of checking, the downside of the miss it catches was an incident. In the worked example below, this pass catches a phone number hiding in a free-text comment field that the script, built for structured columns, sailed past. Free-text fields are where identity goes to hide; assume every comment column is contaminated until proven otherwise.

Drafting the paperwork. Access requests, purpose statements, the tenancy summary paragraph: all standard prose that AI drafts in seconds and you correct in minutes. The purpose statement in particular benefits, because the model will default to a usefully rigid template (data elements, purpose, masking, retention, requestor) that a hurried human tends to abbreviate.

And now the bright red line. Never paste raw, unredacted data into any tool to ask whether it is sensitive. Read that twice, because under deadline it feels so reasonable: "I'll just show it the sample and ask if there's PII in it." The question answers itself by the act of asking. If the sample contained sensitive data, you just sent sensitive data to an external system without authorization, which is the exact event the question was trying to prevent. It is the data-governance version of testing whether the gun is loaded by pulling the trigger. The safe versions of the same task exist and cost minutes: ask about the schema instead of the data, or redact first and ask the model to check your redaction. The raw-paste version is a failure story waiting for a date and a name, and the next section supplies both, hypothetically.

One Half Day, Two Endings: The Worked Example and the Career-Ender

All numbers in both stories are hypothetical illustrations, built to be realistic rather than reported from a specific case. The pattern, unfortunately, is not hypothetical at all.

The pre-flight that cost half a day

Return to the invoice-exception audit that has carried this chapter. Your Process Data Register holds 23 rows: source systems, extracts, reference tables, the works. You block one half day, about four hours, to run the Data Pre-Flight Checklist across all 23, with your sanctioned AI tenant helping on the schema reviews. Here is the tally at the end of the afternoon.

Nine rows: cleared with conditions. Each contains PII (vendor contacts, approver names, bank details in remittance fields) that the pilot's pattern-finding does not need. The condition is masking before sampling. You write one redaction script, about two hours of work including the AI-assisted second-eyes check, and because the register told you which fields recur across sources, that single script gets reused for every sampling exercise in the rest of the chapter. Two hours, amortized across months.

Two rows: blocked pending data-owner authorization. Both involve bank account details, and the owner's first response is hesitation. Here the pre-flight produces its most elegant outcome: instead of fighting for authorization, the pilot design changes to exclude bank details entirely. Exception categorization never needed them. The cheapest fix in the entire audit is the data you decide not to touch, and only a pre-flight run before the design hardened could have found it, because by month three the pipeline would have been built assuming those fields.

One row: routed to legal. A vendor-portal extract is covered by a contract clause about third-party data sharing, and you remember that the model vendor is a third party. Legal's answer takes eight days: usable, with two fields excluded. Started in week one, those eight days cost nothing; the audit proceeds on the other 22 rows. Discovered in month four, that same clause stops the pilot cold while lawyers exchange letters.

One paragraph: the tenancy note. Four sentences recording that all pilot work happens in the enterprise tenant, prompts retained 30 days, no training on company data per the contract, personal accounts out of bounds for anything containing work data. It takes ten minutes to write and it answers, in advance, the exact question a security review will someday ask.

Total cost: half a day of assessor time, one two-hour script, eight days of legal latency absorbed painlessly in week one. Total yield: a pilot that cannot be ambushed by its own data.

The shortcut that taxed a department

Now the other ending, told plainly, because it deserves neither drama nor euphemism. An analyst at a mid-size firm, competent and under deadline, wants to test whether a chatbot can categorize customer complaints. The enterprise tenant request form looks slow. Her personal account is already open. She pastes in 4,000 customer records, real names, real order histories, real email addresses, and the test works brilliantly. The categorization idea is genuinely good. It becomes a pilot proposal, the proposal earns praise, and for three months everything about this story looks like initiative.

Then the pilot's security review asks a routine question: where was the approach originally validated, and on what data? The answer surfaces. The pilot is frozen the same week. The analyst is formally disciplined, not because anyone believes she meant harm, but because 4,000 customers' data left the company's control for a consumer system with unknown retention, and no one can prove where it lives now or make it unlive. And then comes the tax, the part these stories always omit: every future AI proposal from that entire team now routes through a three-week security review, because trust, once spent, is repaid at interest by everyone. Her good idea survived. Her standing did not, and her colleagues' velocity did not. A two-minute pre-flight, or even the one-sentence tenancy rule pinned to a wall, would have redirected that Thursday afternoon completely: same idea, same test, run on a masked sample in the sanctioned tenant, and the story ends with a promotion case instead of a disciplinary file.

Hold the two endings side by side. The difference between them was never intelligence, intention, or even the idea. It was whether the safe path had been made explicit before the pressure arrived. That is the entire job.

What to Do Monday Morning

The pre-flight is a half-day habit, not a project. Start it while this lesson is fresh.

1. Run the Data Pre-Flight Checklist on your register's top five rows. Five questions per row: what is in it, who may see it, where may it travel, how long may it live, who signed. Record one of the four outputs for each. If you finish in under an hour, you were honest about "who signed" on at most two of them; go back.
2. Write your redaction script once. Identify the recurring PII fields across your sources, script the masking (or the pseudonymization if analysis needs consistent stand-ins), and run the AI second-eyes check on the masked output, in the sanctioned tenant, paying special attention to free-text fields.
3. Send the two authorization requests you have been avoiding. You know which two. Write the purpose statement properly (elements, purpose, masking, retention, requestor), send it to the data owner, and start the clock, because the response time is itself an audit finding.
4. Confirm your organization's sanctioned-tool list and tenancy terms. Find the list, or discover it does not exist, which is a level-one finding for your report. For the sanctioned tenant, write the four-sentence tenancy note: where prompts go, retention period, training exclusion, personal-account rule.
5. Add the five flag families as columns in your Process Data Register. PII, contract, tenancy, retention, authorization: one status cell each per row. The register you built for inventory just became a governance instrument, and next lesson it feeds directly into the readiness report leadership will actually read.

Key Takeaways

• Treat privacy, security, and access as a wall, not a triage lane: quality gaps cost the pilot, but violations here cost careers, trigger regulators, and are committed by momentum far more often than malice.
• Run the Data Pre-Flight Checklist per data element before any sample, export, or byte reaches any model or vendor: what is in it, who may see it, where may it travel, how long may it live, who signed.
• Flag and route, never rule: the assessor raises the five flag families and routes each to its owner (privacy, legal, security, data owner), because "route to the legal or privacy owner" is an explicit checklist output and the assessor flags while counsel decides.
• Ask "does the pilot need identity or the pattern?" for every PII exposure, and make redaction or pseudonymization before sampling the default move rather than the exception.
• Remember that the model vendor is a third party under your contracts and NDAs, and that any work data in any unsanctioned tool is a reportable event, not a productivity hack.
• Account for every copy: prompts, logs, exports, and desktop files all have retention lives, and "where will every copy exist in 90 days?" is the question that finds the forgotten CSV before an auditor does.
• Separate access from authorization: being able to open a table is plumbing, while purpose limitation requires a written yes from the data owner, and the timed access request doubles as the authorization test.
• Use AI on schemas, redacted samples, and paperwork drafts, but never paste raw unredacted data into any tool to ask whether it is sensitive, because the act answers the question by committing the violation.