- **Golden Rule of Implementation.** Do not upload real customer files, credentials, or production database access to Claude Code or any cloud model.
- Do not claim legal compliance from tooling alone—have counsel review regulated data (health, payments, kids).
- A person reviews generated code before it touches production data.
- **Disclosure.** Creator counts and demo outcomes were not independently re-run by CrimsonBot.
- This pattern reduces how often real PII is sent to a cloud model; it does not by itself satisfy GDPR, HIPAA, PCI-DSS, or any NDA.
- *This playbook is an educational synthesis intended to operationalize the insights presented in the source video.
- It is not affiliated with or endorsed by Thu Vu, Anthropic, or DataCebo.
- Watch the original for full context.*
Risks
- The real file is still read locally during synthesis. Keep that step offline.
- A synthetic twin can leak rare values or outliers from small tables. Check the twin before you upload it.
- A misconfigured Claude Code session could reach local or production files. Give it the synthetic file only.
- AI-written code can be wrong. A person reviews it before it runs on real data.
- This pattern is not GDPR, HIPAA, or PCI compliance.
Executive summary and core framework
## 1. Executive Summary & Core Architectural Framework Most “analyze my CSV with AI” tutorials skip the part that gets people fired: real customer emails, card numbers, and proprietary metrics leaving your machine. Thu Vu’s approach—regrouped here into three modules—keeps the model away from real records. You build a local synthetic twin, have Claude Code write and debug analysis code against that twin in the cloud, then run the finished code yourself on the real file behind your own firewall. **The thesis.** The old way uploads the real spreadsheet to a chat model and hopes for the best. Vu’s way treats the model as a code author, not a data vault: same columns and types, fake values, inspectable notebooks, then a path swap on your machine.
Core principles from the video
**Core principles from the video** - **You need the code, not the model seeing secrets.** Working, tested analysis scripts matter more than chatting with the raw table. - **Synthetic proxy first.** Generate a fake twin locally that mirrors schema and rough shape, without real customer rows. - **Minimize before you synthesize.** Drop columns you do not need (cards, emails) before modeling. - **Cloud for the twin only.** Upload the synthetic file to Claude Code; keep production folders off that session. - **Run real data locally.** Review the notebook, install requirements, point the path at the confidential file, execute behind your firewall.
Module 1 — Synthetic Twin Generation
## 2. Playbook Modules Covers the local SDV / synthetic-proxy steps from Thu Vu’s video. **Problem statement & benchmark data.** Raw ops tables mix useful facts with PII. Hand-building fake rows breaks dates and types. Vu uses Python’s Synthetic Data Vault (SDV) locally to detect metadata, fit a synthesizer, and sample proxy rows that keep column structure without real people. **Production prompt sequence** **Governance control.** Synthesis still reads the real file on disk—keep that step offline. Never commit `*_REAL.csv` or confidential paths. SDV output is not a legal shield; treat it as a risk-reduction pattern your privacy/security team still reviews.
Prompt **Case study — from the video.** Vu demonstrates building a synthetic proxy of sensitive tabular data with SDV, checking metadata types (for example addresses and emails), then using that twin for downstream analysis work instead of the live file. **Prompt 1 — Local twin checklist (run on your machine, not in cloud chat)** You are helping me plan a LOCAL synthetic twin with SDV (Synthetic Data Vault). Dataset: [PATH ON MY MACHINE ONLY] Goal analysis: [WHAT QUESTIONS I NEED] Do NOT ask me to paste real rows, card numbers, emails, or SSNs into this chat. 1. List columns I should drop before synthesis (high-risk PII not needed for the goal). 2. List columns to keep and the SDV sdtype I should verify (email, address, datetime, categorical, numerical). 3. Give me a short SDV single-table script outline: detect metadata, update_column fixes, fit GaussianCopulaSynthesizer, sample [N] rows to data/[NAME]_synthetic.csv. 4. Remind me to inspect auto-detected metadata before fitting. Do NOT upload anything. Do NOT claim GDPR/HIPAA/PCI compliance. **Prompt 2 — Metadata hardening** I will paste ONLY column names and dtypes (no real values): [COLUMN NAME | DTYPE | INTENDED SDTYPE] Flag mis-typed fields (e.g. address detected as id). Propose metadata.update_column fixes. Then outline how to validate() before fit. Do NOT invent sample PII rows.
Module 2 — Cloud Code Generation on the Twin
Covers prompting Claude Code against the synthetic CSV from Thu Vu’s video. **Problem statement & benchmark data.** Letting a cloud agent browse your whole laptop risks accidental leakage. Vu’s pattern: Claude Code in a cloud session that only receives the synthetic CSV, asked to produce an EDA notebook, charts, and requirements.txt. **Production prompt sequence** **Governance control.** Confirm the Claude Code session cannot see production folders. Upload only `*_synthetic.csv`. Treat model-named “Opus” or other build labels as whatever the product UI shows that day—use Claude as shipped; do not rely on a specific internal model codename from a third-party write-up.
Prompt **Case study — from the video.** Vu uploads the synthetic proxy to Claude Code, asks for analysis (how many nights guests stay and the most common email domains, per her repo prompts), reviews notebooks/dashboards. **Prompt 1 — EDA notebook on synthetic only** Role: Python data analyst. Environment: Cloud session with ONLY the attached synthetic file [SYNTHETIC_FILENAME]. You have no access to my real data or local disks. Build a Jupyter notebook that: 1. Profiles nulls, dtypes, and odd values. 2. Computes [METRIC LIST, e.g. average length of stay]. 3. Flags impossible date pairs (checkout before checkin) without crashing. 4. Adds Plotly charts and markdown explanations. 5. Writes requirements.txt with pinned packages. Do NOT ask for the real dataset. Do NOT call external APIs with row-level data. **Prompt 2 — Defensive cleaning module** Extend the notebook with typed functions for: - date validity buckets - simple cohort segments I define: [SEGMENTS] - a short data-quality warning section for synthetic quirks Output modular .py cells I can re-run later against a different path. Do NOT hard-code secrets. Do NOT exfiltrate rows.
Module 3 — Local Handoff on Real Data
Covers downloading code and running it locally from Thu Vu’s video. **Problem statement & benchmark data.** AI notebooks miss packages or break on bigger production files. Vu’s close: pull the notebook and requirements home, review line by line, venv install, swap the path to the confidential CSV, run locally. **Case study — from the video.** After cloud generation on the twin, Vu downloads the notebook and requirements.txt, swaps the path to the real file, and runs the code locally (also described in her repo README) only on her side of the firewall. **Production prompt sequence** **Governance control.** Human code review before production runs. No “zero leak” guarantees—misconfiguration still hurts. For regulated datasets, stop and get a privacy/security review before rollout.
Prompt **Prompt 1 — Pre-flight before path swap** Review this notebook outline / requirements.txt I will paste (code only, no data): [PASTE] List missing packages, risky network calls, and any path that might still point at cloud uploads. Give me a local checklist: venv, pip install -r, DATA_PATH swap to [LOCAL_REAL_PATH], run command. Do NOT request real rows. **Prompt 2 — .gitignore guardrails** Draft a .gitignore for a private analytics repo that ignores: data/confidential_*, *_REAL.csv, .env, venv/ and allows *_synthetic.csv, notebooks, and .py. Add a short pre-commit idea that greps staged diffs for credit-card-like patterns and blocks the commit. Remind me this is a helper, not compliance certification.
Human checkpoint. A person approves this step before the agent goes further.Master execution and deployment matrix
## 3. Master Execution & Deployment Matrix **Build order:** twin locally → cloud code on twin only → local review and real-path run. Skipping ahead uploads risk. | Module / Focus | Operational Objective | Key Insight / Benchmark | Primary Prompt / Workflow Pattern | Governance & Safety Control | |---|---|---|---|---| | 1 Synthetic twin | Fake schema-matched CSV | SDV locally; drop unused PII columns | Metadata check → fit → sample proxy | Real file stays offline; no cloud upload | | 2 Cloud on twin | Notebook + charts + requirements | Claude Code sees synthetic only | EDA prompt + anomaly flags | No production folder access | | 3 Local handoff | Run on confidential path | Path swap after human review | venv + requirements + pre-flight | Counsel for regulated data; no compliance claims |
Credits and source references
## 4. Credits & Source References **Source video:** Thu Vu (@Thuvu5), "Don't Give AI Your Data: How I (Actually) Use Claude Code for Data Analysis," published Nov 5, 2026 (17:13). https://www.youtube.com/watch?v=IPKOx66fogE — also https://youtu.be/IPKOx66fogE. Prompts here are new writing based on her ideas; watch the original for full context. Her demo repo (from the description): https://github.com/thu-vu92/claude-code-data-analysis. Referral/affiliate-style links in the description include Claude Code trial (clau.de/ThuVu) and her newsletter—those are the creator’s, not ours. **Third parties named** - Synthetic Data Vault (SDV) by DataCebo — https://docs.sdv.dev/ - Anthropic Claude Code — https://code.claude.com/ - Pandas, Plotly (as used in analysis notebooks)