Capstone: Your AI Data Privacy Blueprint

Exercise 1: Audit your current AI data flows

Map every place data leaves your environment for AI processing. Most organisations are surprised by how many AI data flows exist when they actually enumerate them.

Step 1: Identify all AI tools in use

Start with the approved tools:

• Corporate AI assistants (ChatGPT Enterprise, Claude for Work, internal tools)
• AI coding assistants (GitHub Copilot, Cursor, Tabnine)
• AI features embedded in existing tools (Microsoft 365 Copilot, Salesforce Einstein, HubSpot AI)
• AI-powered analytics (Tableau AI, PowerBI Copilot)
• AI search (Perplexity, Google AI Overviews in Workspace)

Then estimate the unapproved tools (shadow AI):

• Consumer AI chatbots (free ChatGPT, free Claude, Gemini)
• AI browser extensions
• AI features in personal productivity tools
• AI APIs accessed by developers on personal accounts

Step 2: For each tool, map the data flow

For every AI tool identified, document:

Step 3: Identify gaps

With the data flow map complete, identify:

• Which flows have no privacy controls?
• Which flows lack DPAs?
• Which flows involve data above the classification level the tool is approved for?
• Which flows involve cross-border transfers without legal mechanisms?
• Which flows are entirely invisible (shadow AI)?

Deliverable: A data flow inventory table covering all AI tools (approved and estimated shadow AI) with the fields above. Highlight gaps in red.

Exercise 2: Classify your data for AI use

Apply the classification framework from Module 2 to your actual data estate. This exercise produces the classification map that drives every technical control in your pipeline.

Step 1: Enumerate your data repositories

List every system that contains data your employees might use with AI tools:

• Customer databases (CRM, support systems)
• Document management (SharePoint, Google Drive, Confluence)
• Code repositories (GitHub, GitLab, Bitbucket)
• Communication archives (email, Slack, Teams)
• Financial systems (ERP, accounting)
• HR systems (HRIS, performance management)
• Healthcare systems (EHR, claims)
• Legal systems (contract management, case management)

Step 2: Apply the classification decision tree

For each data repository, walk through the decision tree from Module 2:

1. Is it public? → Level 1
2. Does it contain PHI? → Level 4
3. Does it contain PCI cardholder data? → Level 4
4. Does it contain direct PII? → Check jurisdiction → Level 3 or 4
5. Does it contain quasi-identifiers? → Level 3
6. Is it tagged as trade secret/IP? → Level 4 or 5
7. Is it under litigation hold or classified? → Level 5
8. Otherwise → Level 2

Step 3: Document the classification

Deliverable: A classification table covering every data repository with its AI classification level, key PII types, applicable regulations, and approved AI processing method.

Exercise 3: Design your privacy architecture

Using the data flow audit (Exercise 1) and the classification map (Exercise 2), design the privacy architecture that enforces the classification decisions.

Choose your architecture pattern:

Based on your classification distribution:

If most data is Level 1-2 (primarily public and internal data): Lightweight architecture — gateway with regex-only detection for basic PII catching. Focus investment on policy and training rather than deep technical controls.

If data spans Level 2-4 (mix of internal, confidential, and restricted): Full gateway architecture — the three-layer detection pipeline (regex + NER + LLM for Level 4), pseudonymisation for Level 3, local inference for Level 4, direct cloud for Level 1-2.

If most data is Level 4-5 (primarily restricted or prohibited): Local-first architecture — local inference as the default, gateway only for tasks that genuinely require cloud model capabilities, with strict approval workflow for cloud routing.

Design decisions to document:

1. Detection stack: Which layers (regex, NER, LLM) and which specific tools (Presidio, spaCy model version, Gemma 4 variant)?
2. Redaction strategy per level: Simple redaction, typed redaction, or pseudonymisation? When is re-hydration needed?
3. Routing rules: What classification levels route to local vs gateway vs cloud?
4. Local inference deployment: What model, what hardware, what capacity?
5. Cloud AI providers: Which providers for which use cases? What DPAs and retention policies?
6. Audit logging: What metadata is captured, what is the retention period, who has access?
7. Monitoring: What metrics are tracked, what triggers alerts?

The architecture diagram:

Draw a diagram showing:

• User-facing AI interfaces (chat, API, embedded tools)
• The gateway (detection, redaction, routing)
• Local inference endpoints (model, hardware)
• Cloud AI endpoints (providers, via gateway)
• Direct cloud endpoints (for Level 1-2, if applicable)
• Audit log collection
• Monitoring dashboard

Deliverable: An architecture diagram with a supporting document covering the seven design decisions above.

Exercise 4: Draft your AI acceptable use policy

Using the policy template from Module 11, draft an AI acceptable use policy tailored to your organisation.

Customisation points:

1. Approved tools: Replace the template placeholders with your actual approved tools, URLs, and access instructions. Be specific about which tools are approved for which purposes.

2. Data classification rules: Map your classification levels (from Exercise 2) to plain-language guidance. Employees should be able to determine the classification of their data within 30 seconds using the simplified decision tree.

3. Department-specific rules: If certain departments handle disproportionately sensitive data (legal, HR, R&D, clinical), add department-specific sections that address their unique requirements.

4. Request process: Define the process for requesting new AI tools or use cases. Include the expected response time, who reviews requests, and what information the requester should provide.

5. Enforcement and consequences: Define proportionate consequences. First-time accidental violations should result in re-training, not disciplinary action. Repeated or deliberate violations warrant escalation.

Review checklist:

Before finalising the policy, verify:

• Every approved tool is named with a URL and access instructions
• The data classification guidance is understandable by non-technical employees
• The prohibited actions list is specific (not "do not misuse AI tools")
• The policy explains why, not just what
• There is a clear process for reporting concerns without fear of punishment
• The policy has a review date (every 6 months)
• Legal, HR, and IT have reviewed and approved the policy

Deliverable: A complete AI acceptable use policy ready for organisational review and approval.

Exercise 5: Map your architecture to your regulatory requirements

The final exercise validates that your privacy architecture (Exercise 3) satisfies your regulatory requirements (identified during classification in Exercise 2).

For each applicable regulation, create a control mapping:

GDPR control mapping (if applicable):

HIPAA control mapping (if applicable):

SOC 2 control mapping (if applicable):

Deliverable: A regulatory control mapping table for each applicable regulation, showing the requirement, the control that addresses it, and the evidence that demonstrates the control.

The one-page AI Data Privacy Blueprint

You now have five supporting documents. Distil them into a single-page blueprint that any stakeholder — CISO, CEO, auditor, board member — can read in five minutes.

AI Data Privacy Blueprint

ORGANISATION: [Your organisation]
DATE: [Date]
OWNER: [CISO / DPO / AI Governance Lead]
REVIEW CYCLE: Every 6 months

━━━ DATA CLASSIFICATION ━━━
Level 1 (Public):     [X]% of AI-processed data → Direct cloud AI
Level 2 (Internal):   [X]% → Cloud AI with enterprise agreement
Level 3 (Confidential): [X]% → Gateway (detect + redact) → Cloud AI
Level 4 (Restricted): [X]% → Local inference only
Level 5 (Prohibited): [X]% → No AI processing

━━━ ARCHITECTURE ━━━
Gateway:    [Tool/custom] with [detection stack]
Local AI:   [Model] on [hardware] for Level 4 workloads
Cloud AI:   [Providers] with [DPAs/BAAs] for Level 2-3 workloads
Audit:      [Logging system] with [retention period]

━━━ KEY METRICS ━━━
Local processing ratio:    [X]% (target: [X]%)
PII interception rate:     [X]% (target: >95%)
Shadow AI rate:            [X]% (target: under 10%)
Detection recall (red-team): [X]% (target: >99% for Level 4)

━━━ REGULATORY COMPLIANCE ━━━
GDPR: [Status] — DPIA completed [date], SCCs in place
HIPAA: [Status] — BAAs in place, Safe Harbor pipeline operational
CCPA: [Status] — Consumer rights process operational
SOC 2: [Status] — AI system in scope for next audit [date]

━━━ ORGANISATIONAL CONTROLS ━━━
Policy: AI Acceptable Use Policy v[X] — [date]
Training: [X]% completion rate, role-based
AI Champions: [X] across [X] departments
Review: Next scheduled review [date]

This blueprint becomes the executive summary of your AI data privacy programme. It is backed by the five detailed deliverables from the exercises, any of which can be produced when an auditor, board member, or regulator asks for details.