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.

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:

Which account. Is [TOOL] on a business/enterprise tier, and should the team use their work login rather than a personal one?
The never list. What categories must never be pasted in? (Customer data, employee data, regulated data, credentials, source code, anything else specific to us.)
The fine list. What’s explicitly fine? Drafts, public documents, internal non-confidential material, sanitized examples.
Sanitizing. If we strip names and identifiers, is the remaining structure acceptable to paste?
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.
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 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 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.

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.
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.
Then write the rules with 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.
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; a filled-in example of the resulting policy is in worked-example.md, section 2; the full rollout sequence is managers-toolkit.md.