# Getting the Yes — written data rules from security, legal, or IT

*Every other document here says "get it in writing from security, legal
or IT" and then moves on. This is the part that actually blocks people
for months. Here's who to ask, exactly what to ask, what to send, and
what to do when the answer is silence — which is the most common answer.*

Two things to know before you start.

**You are not asking for permission to use AI.** That question invites
a committee. You are asking a narrow, answerable question: *given that
we already have `[TOOL]`, what may my team put into it?* One is a
policy decision someone has to own. The other is a factual question
someone can answer in ten minutes.

**Silence is the default outcome, not rejection.** Most of these emails
aren't refused; they're deprioritized. Everything below is designed
around that: make it cheap to answer, easy to say yes to, and awkward
to leave unanswered.

---

## 1. Work out who actually answers

Ask the wrong person and you get a referral loop. The right person
depends on what's already true at your company.

| If… | Ask | Why |
| --- | --- | --- |
| IT rolled out the tool company-wide | **IT / the person who owns the rollout** | They've almost certainly already been asked this. There may be an answer sitting in a document. |
| There's an infosec or security team | **Security** | Data handling is their remit and they answer factual questions faster than legal does. |
| You're regulated (health, finance, legal, public sector) | **Compliance**, copying security | The binding constraint is regulatory, not technical. |
| You're in the EU/UK, or handle personal data | **The data protection officer or privacy lead** | This is squarely their job and they usually have a position already. |
| Under ~50 people, no security team | **Whoever owns the IT contracts** — often ops, finance, or a founder | See [section 7](#7-if-nobody-owns-this). |

**Before you send anything, spend ten minutes looking.** Search your
intranet, wiki, and the all-company channel for "AI," "ChatGPT,"
"Copilot," and "generative." An acceptable-use policy that already
covers this exists more often than you'd think, and finding it saves
you three weeks. If you find one and it's vague, your email gets much
easier — you're asking someone to clarify an existing document rather
than write a new one.

**Ask your own manager who to ask.** Thirty seconds, and it usually
comes with the name of the person who actually decides rather than the
person on the org chart.

---

## 2. Ask five answerable questions

The reason these emails stall is that they ask something open-ended.
"Can we use AI?" has no bounded answer, so it becomes a project.

Ask instead for a yes/no or a short list on each of five things:

1. **Which account.** Is `[TOOL]` on a business/enterprise tier, and
   should the team use their work login rather than a personal one?
2. **The never list.** What categories must never be pasted in?
   (Customer data, employee data, regulated data, credentials, source
   code, anything else specific to us.)
3. **The fine list.** What's explicitly fine? Drafts, public documents,
   internal non-confidential material, sanitized examples.
4. **Sanitizing.** If we strip names and identifiers, is the remaining
   structure acceptable to paste?
5. **Who to ask.** Who should my team contact when they hit a
   borderline case?

Question 3 is the one people forget and it's the one that changes
behaviour. A reply that only lists prohibitions leaves your team
guessing about everything else, and guessing resolves as "don't."

Question 4 is worth asking explicitly because sanitizing is the answer
to most real cases — the team usually needs the shape of the data, not
the records.

---

## 3. The email

Short, specific, pre-answered, with a deadline and a default. Replace
the brackets.

> **Subject:** Quick sign-off needed: what data can my team put into
> `[TOOL]`?
>
> Hi `[NAME]`,
>
> We've had `[TOOL]` licenses since `[DATE]` and I'm about to get my
> team of `[N]` using it properly for `[e.g. drafting, summarizing
> reports, reading long documents]`. Before I do, I want the data rules
> in writing so I'm publishing your answer rather than my guess.
>
> I've drafted what I *think* the rules are, below. Could you correct
> anything that's wrong and reply "confirmed" on the rest? I'm not
> asking for a policy document — just a reply I can quote.
>
> **1. Account:** Team uses their `[COMPANY]` login on our
> `[business/enterprise]` tier, never a personal or free account.
>
> **2. Never goes in:** customer/client data identifying real people;
> employee data; anything under NDA or marked confidential; regulated
> data (`[health / financial / legal]`); credentials and API keys;
> `[ANYTHING SPECIFIC TO US]`.
>
> **3. Fine to use:** our own drafts and notes; published/public
> material; internal process docs that aren't confidential; sanitized
> examples with names and identifiers removed.
>
> **4. Sanitizing:** where we need to work with real material, we strip
> names, reference numbers, and identifiers first and paste only the
> structure. Assuming that's acceptable to you?
>
> **5. Questions:** my team will bring borderline cases to `[ME /
> OWNER]`, who'll come to you if it's genuinely unclear. Is that the
> right route, or would you prefer they contact you directly?
>
> If I haven't heard back by `[DATE — 10 working days out]`, I'll tell
> the team that AI use is limited to public and made-up material only
> until you confirm, and that everything else is on hold. I'd rather not
> run that way for long, so any steer at all is welcome — even "not yet,
> ask me in three weeks."
>
> Happy to do this on a 15-minute call instead if that's faster.
>
> Thanks,
> `[YOU]`

**Why it's built this way.** You've converted "write us an AI policy"
into "read five lines and correct them" — the difference between an hour
of their time and four minutes.

**Note what the deadline does and doesn't say.** It does not say "I'll
publish these rules and proceed." You are not in a position to authorize
your own company's data handling, and a document you wrote that permits
customer data to be pasted into a tool is not made safe by the word
"provisional" at the top of it. What the deadline commits you to is the
*restrictive* default — narrowing what your team may do, which is
entirely within your authority as their manager. That's still real
pressure, because a manager telling their team "we're paused pending
security" is a visible cost that tends to produce a reply.

**Copy your own manager.** Not to apply pressure — to make sure the
person reading it knows this is real work with a sponsor, not one
person's side project.

---

## 4. When the answer is silence

The most likely outcome. Work through this in order.

**Day 10 — publish the interim notice, not a policy.** Do exactly what
you said you'd do, and not one inch more. The thing you send your team
is a *restriction*, not a rulebook:

> **AI use at `[TEAM]` — interim, `[DATE]`**
>
> We've asked `[NAME / TEAM]` to confirm in writing what we may put into
> `[TOOL]`. Until that comes back, here's where we stand.
>
> **You can use `[TOOL]` on your `[COMPANY]` account for:**
> - Anything already public — our website, published material, public
>   documents
> - Material you've made up yourself for the purpose: invented names,
>   invented numbers, a fake example with the same shape as the real
>   thing
> - Anything `[NAME / TEAM]` has already approved in writing:
>   `[LIST IT, OR "nothing yet"]`
>
> **Everything else is on hold** — no customer or client material, no
> employee data, no internal documents, and no real records even with
> names removed. Not because we think it's unsafe, but because we don't
> have the answer yet and it isn't mine to give.
>
> This is deliberately narrow and I expect it to loosen. If a piece of
> work is blocked by it, tell `[OWNER]` — a list of concrete blocked
> tasks is the most useful thing we can take back to `[NAME / TEAM]`.

Then send that to the person you asked: *"Here's what I've told the team
in the absence of an answer — it's restrictive, and I'd rather replace it
with your actual rules."*

**Do not write the never-list and fine-list yourself.** Publishing a
document that permits real company data, however hedged, means you have
decided your organization's data-handling position on behalf of the
people accountable for it. If it turns out to be wrong, "it said
provisional" protects nobody — not you, not your team, and not whoever's
data it was. The interim notice above works precisely because everything
it permits is material where the answer can't be wrong.

**Day 12 — the one-line nudge.** Not a re-send. A reply on your own
thread:

> Just the one question if the rest is too much: is it OK for the team
> to paste `[THE SPECIFIC THING YOU MOST NEED]` — names and identifiers
> removed — into `[TOOL]` on our `[TIER]` account?

One question, yes or no, ten seconds to answer. This gets a reply when
the full email didn't, and one confirmed yes unblocks real work — write
down who said it and when, and add it to the approved line of your
interim notice.

**Day 20 — change the channel.** Email isn't working, so stop using it.
Find them in person, on a call, or in a shared channel and ask the
one-liner out loud. "I sent you something a couple of weeks ago — can I
just ask you the one bit I actually need?" A verbal yes is worth
having; follow it with *"Great — I'll write that down as confirmed by
you on `[DATE]`, shout if I've got it wrong."* That sentence turns a
hallway answer into a citable one.

**Day 30 — escalate correctly.** Not "security is blocking us," which
is both untrue and makes an enemy. Ask your manager to ask their
counterpart:

> My team has had `[TOOL]` for a month and I've had to hold them to
> public and made-up material only, because I can't get our data rules
> confirmed and it isn't my call to make. That's costing us `[the
> specific blocked work]`. Could you nudge `[NAME]`'s manager?

The blocked-work list is what makes this land. "We're waiting" is easy
to ignore; "we're waiting and here are the four things not happening
because of it" is not.

**What you must not do:** wait indefinitely and quietly. A team held for
a quarter on an unanswered email doesn't stay still — people start using
their personal accounts, unsupervised, with no rules at all. That's the
outcome the whole exercise exists to prevent, and it's the strongest
argument you have. It's fine to say so out loud: *"the practical
alternative to written rules isn't no usage, it's unwritten usage."*

Note the shape of that argument, though. It's a reason for **security to
answer you**, not a reason for you to answer for them. If the wait drags
on, the thing that escalates is the volume of your asking — not the scope
of what you've permitted.

---

## 5. When the answer is no, or nearly no

Most no's aren't what they look like. Find out which one you've got.

| What you hear | What it usually means | What to do |
| --- | --- | --- |
| "We're forming a working group" | Six months, minimum | Ask for interim rules *for your team only*, explicitly time-boxed until the group reports. Much easier to grant than a company position. |
| "Nothing confidential, full stop" | Reasonable and probably fine | Take it. Most first use cases don't need confidential data. Check your scoring sheet — the high scorers rarely do. |
| "Not until we've done a vendor review" | A real process with a real queue | Ask where it is in the queue and who owns it. Meanwhile ask what's permitted with *public and internal-only* material — usually the answer is "that's fine." |
| "Use the free version, it's cheaper" | They may not know the tiers differ | Worth checking together rather than asserting. Consumer and business tiers of the same product often differ on retention and on whether inputs train future models — look up what your specific tier actually says and send them the page. Where it favours the paid tier, that's a security argument for the licence, not against it. |
| "Legal says no" (from someone who isn't legal) | A rumour, most of the time | Ask who in legal, and when. Go to them directly. This frequently evaporates. |
| A real, considered no | Genuinely no | Stop. Then see below. |

**If it's a genuine no,** you still have most of the toolkit. The team
can use it on public material, on their own drafts, on explaining
things, on structure and format — none of which requires your data.
Write the policy around what *is* allowed, publish it, and be
scrupulously clean about the line. The fastest way to a yes in six
months is a documented quarter of nothing going wrong.

And write down what the no was based on, with a date. Tool terms
change, tiers change, and "we looked at this in early 2026" is exactly
what makes it reasonable to ask again.

---

## 6. What you can do while you wait

Don't idle. Everything here is unblocked with zero approvals, because
none of it involves company data:

- **Name the owner** and protect their hours.
- **Take the baseline survey.** Five questions, ten minutes, and you
  can't recover it later.
- **Run the dread question** in a team meeting and score what comes
  back — sheet 1 of
  [operating-templates.md](./operating-templates.md).
- **Do your own micro-pilot** on your own non-sensitive work, so you
  can speak from experience.
- **Draft the policy** with every bracket filled except one: leave the
  never-list blank, ready for the answer. Drafting it is fine —
  publishing it is what waits.
- **Draft the prompts** using [prompt-recipes.md](./prompt-recipes.md)
  against made-up examples with the same shape as your real material.

That's most of the ground-rules step done in parallel with the wait
rather than after it. What none of it does is put real company material
into the tool — that's the line, and it holds until someone with the
authority to move it says so in writing.

---

## 7. If nobody owns this

Small companies, startups, teams inside organizations where the answer
is genuinely "nobody has thought about it." You're not blocked — you're
the one who decides, and you should be deliberate about that rather
than accidental.

**This is not the silence case.** If there is a security, legal, IT,
compliance, or privacy function and they simply haven't replied, you are
not in this section — go back to [section 4](#4-when-the-answer-is-silence)
and keep the interim restriction in place. The difference that matters
isn't how long you've waited; it's whether anyone else holds the
authority. If someone does, it stays theirs.

1. **Read the actual terms of your tool's tier.** Specifically: is
   input used for training, how long is it retained, and where. This is
   fifteen minutes on the vendor's trust or privacy page, and it's the
   whole factual basis.
2. **Get it signed off by whoever does own company risk** — a founder, a
   COO, the person who signs the contracts. In a company with no security
   team there is still someone accountable for a data incident, and it
   should be their name on the rules, not yours. One paragraph and a
   reply is enough.
3. **Then write the rules** with
   [ai-policy-template.md](./ai-policy-template.md), and say plainly at
   the top who approved them and when: *"Approved by `[NAME]` on
   `[DATE]`. We don't have a formal company policy yet; these are ours
   until we do."* If you genuinely cannot get anyone to sign off, publish
   the interim notice from section 4 instead and keep asking.
4. **Default conservative on the never-list.** It's much easier to
   loosen a rule later than to explain a leak.

A team policy written by a manager, signed off by whoever carries the
risk, and shared openly is a good outcome — plenty of company-wide AI
policies started exactly that way.

---

## 8. Once you have it

- **Quote it verbatim** in section 2 of your policy. Don't paraphrase a
  security answer into something slightly broader or narrower.
- **Record who and when.** "Confirmed by `[NAME]`, `[DATE]`" at the
  bottom of the policy, and in
  `workshop-starter/context/data-rules.md` if you're using the starter
  project.
- **Re-confirm quarterly**, in one line: *"Still accurate? Reply yes."*
  Tools change tiers and terms, and a stale rule teaches people to
  ignore the whole document.
- **Say who approved it when you publish.** "Confirmed with `[NAME]` in
  security" does more for adoption than any amount of reassurance from
  you. It's the sentence that tells the cautious half of your team that
  using the tool is the sanctioned choice, not the risky one.

---

*Related: the policy this unblocks is
[ai-policy-template.md](./ai-policy-template.md); a filled-in example
of the resulting policy is in
[worked-example.md](./worked-example.md), section 2; the full rollout
sequence is [managers-toolkit.md](./managers-toolkit.md).*