What to do when AI isn't allowed to see the real data

Security said no to connecting AI to the system that holds the real records. That’s usually the end of the conversation, and it shouldn’t be. Most of what people want AI’s help with, a report structure, a set of test cases, a draft email using the fields you have, doesn’t need the real numbers. It needs something shaped like them.

This is about building that something.

---

The rule

Match the shape. Never the values.

Same columns, same data types, same relationships between records. Names, amounts, dates, and identifiers that are entirely made up. If a real customer’s name, a real dollar figure, or a real account number would appear anywhere in what you paste, stop and replace it first.

Read your organization’s data policy before you start. If nothing is written down, treat any record you can look up on a real person or account as off limits, full stop.

---

Step 1: describe the shape, not the row

Open a blank document and write down the structure of the real data without touching the real data itself.

Fields and types: [name: type, e.g. "order_date: date", "region: one of 4 fixed values"]
Row count you're working with: [roughly how many]
Relationships: [what links to what, e.g. "one customer has many orders"]
The pattern you actually care about: [what you're trying to show, test, or explain]

That last line is the one people skip. A sample dataset built to “look realistic” and a sample dataset built to show the pattern you’re actually working with are different files, and only one of them is useful.

---

Step 2: ask for the sample, not the analysis

Paste the shape from step 1 into your AI tool and ask for fabricated rows, not conclusions yet.

Generate [N] rows of fake data matching this structure exactly:
[paste your field list]

Requirements:
- Every name, ID, and identifier must be obviously fake
- Include the pattern described here: [paste "the pattern you actually care about"]
- Include a few rows that break the pattern, so I can test edge cases
- Output as a table or CSV, not prose

Asking for a few rows that break the pattern matters as much as the rows that fit it. A dataset with no edge cases produces a report or a test plan with no edge cases either, and the real data will have some.

---

Step 3: do the actual work against the sample

Now ask for whatever you originally needed, the report layout, the test cases, the summary format, the email draft, against the fake data you just generated.

This is where the earlier discipline pays off. Because the sample matches the real shape, whatever comes back, a query, a template, a set of test cases, transfers to the real system with names and numbers swapped back in. You’re not throwing the output away and starting over. You’re handing it a different data source.

---

Step 4: check what actually depends on the values

Before you use the output on real data, separate what it produced into two piles.

Structural, and safe to reuse as-is: column layout, report sections, a query’s logic, a test case’s steps, an email’s template. This is most of what a good prompt in step 3 produces.

Value-dependent, and needs a fresh look once real data is in: any specific number quoted in a summary, any claim about “the largest” or “the most recent” record, anything that sounds like a conclusion rather than a structure. A conclusion drawn from fake data is fake, no matter how confidently it’s phrased.

---

Worked example

The task: build a quarterly usage report for an internal tool, using data that lives in a system with no AI connection allowed.

Shape described: user_id, department, logins_last_30_days, feature_flags_enabled (list), last_active_date. Pattern that mattered: a handful of departments barely use the tool, and the report exists to make that visible to their managers.

Sample built: 40 fake users across 6 fake departments, with two departments deliberately given near-zero activity to match the real pattern, plus a few users with no last_active_date at all, since the real data was known to have some.

What came back and was safe to keep: the report’s grouping logic, the low-usage flag threshold as a formula, the layout showing department against a red-to-green scale. What had to be redone with real numbers: every sentence in the summary that named an actual percentage or department.

---

When it breaks

The sample looks nothing like the real data once you swap it in. The shape in step 1 was too thin. Go back and add the constraints that actually matter: value ranges, which fields are usually blank, which combinations never occur together.

It quietly invents a fact about your real business while working with fake data. It doesn’t know it’s fake unless you told it, and it will write in a confident, informed tone regardless. Anything that reads like a claim about your actual company, rather than a claim about the sample table in front of it, gets discarded, not lightly edited.

You’re not sure whether something counts as “the real data.” Ask the more cautious question: could this row be traced back to an actual person, account, or deal? If yes, it’s real data, even if it’s just one field out of twenty.

The task genuinely can’t be separated from the real records. Some work, an actual audit of production data, a lookup that only makes sense against real accounts, doesn’t have a fake-data version. That’s a real wall, not a prompting problem, and the honest answer is that this task needs the access you don’t have.

---

What you’re not getting

A sample dataset proves your process works. It doesn’t prove the real data behaves the same way, and it can’t catch a data quality problem specific to the real system, a field that’s supposed to never be blank but sometimes is, a value that should be unique but isn’t. Those only show up once you run the finished process against the real thing, by hand or through whatever access you actually have.