How to Design AI Usage Policies for Every Department: Building a Two-Layer Framework of Company-Wide and Team-Level Rules

HR handles a great deal of personal data, so they’d rather tread carefully. Sales, meanwhile, want to lean on it far more for prep ahead of client meetings.

This is the sort of tension that tends to land on the desk of whoever has been handed responsibility for the company-wide generative-AI policy, alongside their counterparts in IT, HR, sales and corporate functions. The old assumption was that a single set of blanket rules — “don’t enter confidential information”, “a person checks the output” — would be enough to keep things in hand. These days that no longer holds: each department deals with different information, different customer touchpoints and different lines of accountability, so a one-size-fits-all AI policy tends to leave people on the ground unsure how to proceed.

Suppose ten departments and fifty people in total begin using the tools. HR is handling personal data, sales is handling customer information, finance is dealing with undisclosed figures, and the planning team is researching public information — the nature of the risk shifts from one department to the next. International guidance such as the OECD AI Principles sets out the thinking that, mindful of AI’s benefits and risks, those involved should take the measures they need themselves. On data protection specifically, the UK ICO’s guidance on AI and data protection sets out how to handle personal data properly when using generative-AI services.

This article sets out a “two-layer” approach: company-wide rules that everyone observes without exception, and departmental rules adjusted to each team’s reality. The aim is a state in which control is not weakened and every department can use AI without hesitation. That said, writing rules does not, on its own, make them stick. They need to sit alongside training, a place to ask questions, access management and regular review, and to be nurtured into a shape that genuinely fits your own workplace.

Why uniform rules alone stop working

When drawing up rules for generative AI, most organisations begin by setting out what everyone across the company must observe.

Rules of roughly this kind, for instance:

Do not enter personal or confidential information
Do not pass AI output straight to outside parties
Have a person check figures, dates and proper nouns
Refer anything touching contracts, legal matters, finance or personnel evaluation to the relevant specialist function
If something feels uncertain while you’re using it, consult IT or the DX team

These are the basic rules almost any organisation will need. If departments start using the tools without a shared company-wide baseline, judgements about what may safely be entered drift apart, and clawing control back afterwards becomes hard.

On the other hand, trying to run everything off company-wide rules alone throws up a different problem. For the sales team, there are plenty of moments where they’d like to use AI — preparing for meetings, drafting the first cut of a proposal. HR, however, deals with personal and evaluation data and needs to exercise rather more caution. Finance can put it to work tidying up already-published material, but should steer clear of entering undisclosed results or anything touching cash flow.

In short, “may we use AI here?” cannot be settled by a single company-wide ruling. In practice you need to pin down which department, for which task, with which information, processed to what extent, and checked by whom.

This is where it helps to separate company-wide rules from departmental ones — the “two-layer” approach.

What the two-layer approach means

The two-layer approach designs your AI policy as two distinct parts:

Layer one: company-wide rules: The baseline every department must observe without fail. This covers information that must never be entered, accountability for checking output, review before any external use, account management, and reporting when an incident occurs.
Layer two: departmental rules: The practical rules adjusted to each team’s work — sales, HR, finance, IT, marketing and so on. They set out which tasks are fair game, how to mask information before entering it, who reviews the output, which prompts may be stored, and where to turn for advice.

With only company-wide rules, people on the ground are left wondering “so, in this particular case, am I allowed to use it or not?” With only departmental rules, the standards the company as a whole ought to uphold drift apart.

So the order matters: first draw the line everyone must observe, then adjust the detail to each department’s reality. Designing it in that sequence is what counts.

What company-wide rules should settle

With company-wide rules, the trick is not to over-specify down to fine procedural detail. What belongs here are the things common to every department — the ones that, if not observed, tend to lead to serious trouble.

Be clear about what must never be entered

The first thing to settle is the information that must never be put into AI.

Information of the following kinds, for instance, calls for careful handling right across the company:

Personal data such as names, addresses, telephone numbers and employee numbers
Highly sensitive information such as health data, beliefs, national ID numbers and bank-account details
Undisclosed results, M&A information and personnel-move information
Customers’ confidential information and contract terms
Credentials, private keys, passwords and vulnerability information

When using generative-AI services, organisations and public bodies that handle personal data must do so properly and in line with data-protection law. Authoritative English-language guidance on this is published in the UK ICO’s guidance on AI and data protection.

What matters is not stopping at an abstract phrase like “don’t enter confidential information”. You need a level of detail fine enough to answer concrete questions: “May I include the customer’s name?” “Is it enough to redact the contract value?” “Can I use the minutes of an internal meeting?”

Decide who is accountable for the output

Work on the basis that AI output is always checked by a person before use. This is worth spelling out explicitly as a company-wide rule.

The following, in particular, cannot go unchecked:

Figures
Dates
Proper nouns
Quotations
Anything touching law, regulation or contracts
Anything touching personnel evaluation or terms of employment
Text being sent outside the company

NIST AI Risk Management Framework sets out an approach to managing AI risk in terms of its impact on individuals, organisations and society. Its Generative AI Profile likewise recommends weighing risk-management actions against the organisation’s own objectives and priorities.

What matters here is settling who actually does the checking. A sales email: the rep and their line manager. Anything contractual: legal. An evaluation comment: the manager. A reply on HR policy: the HR team.

Write only “a person checks it” and, in practice, accountability becomes vague. Rules with no clear owner tend not to function in a busy workplace.

Set the principles for accounts and access

To run the AI environment safely, account and access management also needs to sit within the company-wide rules.

Principles of roughly this kind, for instance:

Do not create shared accounts
Change the access of leavers and movers promptly
Admit only the people who need it to places where highly confidential information is handled
Keep the number of people with administrator rights small
Separate access scope by department or by project

Kanata is organised around the concepts of spaces, projects, apps and libraries, with a structure that lets you manage members and permissions on a per-project basis. Arrangements like this help when you want to separate the scope of use by department or by task. Even so, which units you divide information into, and who is granted which permissions, still has to be designed as the organisation’s own operating rules.

Decide how to act when an incident occurs

With AI, there’s always a chance someone enters information that should never have gone in. What matters then is not blaming the individual, but building a system in which things get reported quickly and accurately.

At a minimum, the company-wide rules would do well to settle the following sequence:

The moment you notice a mistaken entry, stop continuing that conversation
Record what was entered, when, and into which environment
Report to your line manager, IT and the information-security lead
Check the scope of impact as needed
Feed measures to prevent recurrence back into the rules and the training

If there’s an atmosphere in which “the person who slipped up gets a telling-off”, reporting may well be slow. AI rules need to settle not just the prohibitions but how everyone moves when something goes wrong.

What departmental rules should settle

Once the company-wide rules have set the baseline, the next step is to draw up the departmental ones.

For departmental rules, sorting through these six points makes the design easier:

Which tasks AI may be used for
Which information may be entered
Which information should be processed or masked before entry
How far the output may be used
Who does the checking
Where to turn when in doubt

Departmental rules that are drawn up in too much detail tend not to get read. Rather than aiming for a flawless policy from the outset, it’s more realistic to begin with the tasks that come up most often and revisit things after thirty or ninety days. Those intervals are only illustrative; in practice, adjust them to the size of the organisation, the number of users and the sensitivity of the information involved.

A worked example of departmental AI rules
Department	Tasks that lend themselves to AI	Information to watch	Points to check
Sales	Meeting prep, outline drafts for proposals, email first drafts, tidying up meeting notes	Customer information, contract terms, contact names, contract values	The rep and line manager check before anything goes outside the company
HR	Training notices, policy explanations, internal FAQs, structuring interview notes	Personal data, evaluation data, health data, disciplinary and grievance information	Policy answers are checked against their basis in the rules; evaluation comments are checked by the manager
Finance	Tidying up published material, internal procedure documents, expense-claim FAQs	Undisclosed results, cash flow, M&A information, anything touching investment decisions	Figures are reconciled against the source; anything touching external disclosure is checked by a specialist
IT	Internal FAQs, procedure documents, query triage, first drafts of incident reports	Credentials, private keys, access tokens, undisclosed vulnerability information	Defer to the formal procedure document and the responsible person’s judgement
Marketing	Article outlines, ad copy, email copy, webinar plans, draft social posts	Pre-publication information, customer case studies, competitor comparisons, performance figures	Check the source, whether it may be published, any permission to feature it, and for overstatement

A worked example for the sales team

The sales team has no shortage of moments where they’d like to use AI: preparing for meetings, drafting proposal outlines, first cuts of emails, tidying up meeting notes, pulling out next actions.

At the same time, sales comes into contact with customer and contract information often, so the rules for masking before entry matter a great deal.

Departmental rules of roughly this kind might apply, for instance:

It may be used for meeting prep and first drafts of proposals
Mask customer names, contact names and contract values as needed
Handle anything under NDA only after checking the contract terms
Emails and proposals going outside the company are checked by the rep and line manager
Don’t let AI output alone decide commitments on price, contract terms or delivery dates

For the sales team, making clear “how far you can go” is easier to act on than broadly forbidding “you mustn’t use it”.

A worked example for HR

HR has room to put AI to work, but it also handles a great deal of personal and evaluation data, so its departmental rules need designing with care.

Tasks that lend themselves to it include drafting the wording of training notices, tidying up internal FAQs, drafting policy explanations and structuring interview notes. Evaluation comments, health data, disciplinary matters and harassment grievances, by contrast, should not be entered into AI as they stand.

HR’s departmental rules might look like this:

It may be used for first drafts of training material, policy explanations and internal FAQs
Interview notes from which an individual could be identified are masked as a matter of course
Highly sensitive information such as health data, beliefs and family circumstances is not entered
Evaluation comments may draw on AI output for reference, but in the end the manager checks them in their own words
Policy answers to staff are always checked against their basis in the work rules or internal regulations

For HR, “avoiding misunderstanding” and “causing the individual no detriment” need to come ahead of “efficiency”.

A worked example for finance

Finance can put AI to work tidying up already-published material and drafting internal procedure documents. Undisclosed results, cash flow, M&A and anything touching investment decisions, on the other hand, need particularly careful handling.

A departmental example might run as follows:

It may be used to summarise published IR material and internal procedure documents
It may be used to draft FAQs on expense-claim rules and invoice processing
Undisclosed results, cash flow and M&A information are not entered
Any output containing figures is always reconciled against the source
Anything touching external disclosure or audit is checked by a specialist

In finance, an error in the numbers can lead to serious trouble. It’s important to position AI not as the decision-maker but as an aid for tidying up and drafting.

A worked example for IT

IT can use AI for internal FAQs, procedure documents, handling queries and first drafts of incident reports. As it deals with credentials and vulnerability information, though, drawing the line on what must never be entered matters.

The rules might run as follows:

It may be used to produce internal IT procedure documents and FAQs
It may be used to triage queries and draft suggested replies
Passwords, private keys and access tokens are not entered
Undisclosed vulnerability or configuration information is not entered
When handling an incident, defer to the formal procedure document and the responsible person’s judgement over AI output

IT is at once the team driving AI adoption forward and the one safeguarding the whole company. It therefore needs to keep its own internal usage rules distinct from its duty to account to the wider organisation.

A worked example for marketing

Marketing has plenty of tasks that lend themselves to AI: article outlines, ad copy, email copy, webinar plans, draft social posts. Care is needed, though, when handling pre-publication information, customer case studies, competitor comparisons or performance figures.

The rules might run as follows:

It may be used for research, outlines and first drafts built on public information
Performance figures and case studies are checked for their source and whether they may be published
Customer names and case-study content are checked for permission to feature them
Advertising claims, comparative claims and claims about results are checked by a person
Avoid overstatement and categorical assertions

Marketing can lift production speed with AI, but accountability for what’s said stays with the company. In B2B services especially, managing claims so as not to erode trust matters.

Build departmental rules together with departmental representatives

If IT or the DX team draws up departmental rules on its own, the result tends not to fit the work on the ground.

A task that looks high-risk to IT, for instance, may be everyday and essential for the sales team. Conversely, what looks to sales like simply putting a proposal together may, to legal or finance, call for care over how contract terms and figures are handled.

For that reason, it’s important to build departmental rules together with each department’s representatives.

As for how to go about it, the following sequence is realistic:

Each department takes stock of the tasks it would like to use AI for
Classify the information handled in those tasks
Separate out information that may be entered, that should be masked, and that must never be entered
Decide who checks the output
Begin by running three to five representative tasks
Around thirty days in, gather the queries and the cases that gave people pause, and review

Trying to cover every task from the outset means the rule-making alone eats up time. Beginning with the tasks that come up often and whose risk is easy to manage tends to help adoption stick.

How to look after the departments that tend to drift away

When drawing up AI rules, don’t fix your gaze solely on the departments keen to adopt them. If anything, what matters is how you look after the cautious departments and those for whom the reason to use AI is hard to see.

For cautious departments, provide a route to ask rather than a ban

HR, legal, finance and IT are, by the nature of the information they handle, prone to caution over AI adoption.

Broadly forbidding such departments to “use it” simply shuts off AI’s possibilities. Letting them use it while everything stays vague, on the other hand, raises the risk.

What’s needed, then, is “a route to ask when in doubt”.

Arrangements of roughly this kind, for instance:

Provide a point of contact for cases where the judgement is unclear
Turn the common queries into an FAQ
Have departmental representatives join a monthly rule review
For tasks that cause unease, start by trying it with public or already-masked information only

The more cautious the department, the more it can use AI with confidence once the rules are clear.

For enthusiastic departments, hand over standard templates

Sales, marketing and planning are departments that readily feel AI’s benefits.

Left to use it freely, though, the quality of prompts and output drifts. This is where putting together standard templates helps.

Templates of roughly this kind, for instance:

A template for tidying up meeting notes
A template for structuring a proposal
A template for drafting an email
A template for an article outline
A template for organising research angles

Kanata lets you add apps such as AI chat, AI summarisation and e-learning on a per-project basis, and manage prompts and training data as a library. Arrangements like this sit well with putting together standard templates per department and making them easy to reuse.

That said — and this holds whichever AI tool you use, not just Kanata — you still need separate rules for managing the prompts and material you register. The tool’s features alone do not automatically put the operating rules themselves in order.

For departments that aren’t using it, create a small success story

Not every department will be keen on AI from the outset.

Some will feel “I’m not sure what to use it for”, “it has nothing to do with our work” or “I’d be afraid of getting it wrong”.

In that case, beginning with low-risk tasks helps.

Tasks of roughly this kind, for instance:

Summarising public information
Tidying up meeting agendas
Drafting first cuts of internal text
Sorting out FAQ headings
Drafting the outline of training material

The first aim is not to deliver some grand result. It’s to leave people feeling “this task, at least, seems fine to use it for”.

The practical steps for building two-layer rules

From here, let’s set out the steps for actually building the two layers.

Take stock of where each department would use it

First, draw out the tasks each department would like to use AI for.

At this stage, it’s important not to rule on “may we use it or not” first. Begin simply by gathering the situations in which people on the ground would like to use AI.

Sort through it along these lines, for instance:

Which tasks they’d like to use it for
What sort of information they’d be likely to enter
Who will use the output
Whether it might end up outside the company
How great the impact would be if it were wrong

The tasks that come out of this are then sorted, after the fact, into “permitted”, “permitted with conditions” and “forbidden”.

Decide what to forbid and require company-wide

Next, settle the company-wide rules.

Here you sort through the items that must be observed regardless of any department’s particular circumstances.

The main items are as follows:

Information that must never be entered
Accountability for reviewing output
Checking before any external use
Account and access management
Incident reporting
How logs and history are handled
The scope of AI environments that may be used

Over-specify at this stage and the gap with the departmental rules disappears. With company-wide rules, the trick is to narrow them to “the minimum everyone must observe”.

Sort each department into permitted, permitted-with-conditions and forbidden

Next, sort each department’s tasks into three:

Permitted: Relatively low-risk tasks such as summarising public information, drafting internal documents and tidying up meeting agendas.
Permitted with conditions: Tasks that call for masking or review, such as meeting notes containing customer information, FAQ answers that draw on internal regulations, and drafts of evaluation comments.
Forbidden: Tasks where information should not be entered into AI, or decided on AI output alone — highly sensitive information, undisclosed financial information, credentials, weighty legal judgements and the like.

Building this classification per department makes judgements easier on the ground.

Review with departmental representatives

Once a draft set of rules is ready, always review it with departmental representatives.

The points to check are as follows:

Does it fit the actual work
Has it become so strict that it can’t be used
Are there gaps or omissions
Is it clear who does the checking
Is it clear where to turn for advice
Can it be understood in the language people on the ground actually use

“Can it be understood in the language people on the ground actually use” matters most of all. If the rules read like a legal document, they won’t get read on the ground. AI rules need both the precision of a formal policy and the plain clarity to be usable in practice.

Review it regularly

AI rules are not a case of writing them once and being done.

What generative AI can do, and how it’s used internally, both shift over short periods. Rather than aiming for a finished article from the outset, it’s more realistic to design with review built in.

You might review items of this kind, for instance:

The items that drew the most queries
The cases that gave people on the ground pause
Templates that went unused
Prompts that were used often
Near misses
Tasks that should newly be added
Rules that proved too strict
Prohibitions that were vague

As for how often to review: thirty days in at the start, then quarterly, is one illustrative pattern. In practice, adjust it to the size of the organisation, the number of users and the sensitivity of the information involved.

Mistakes worth avoiding when designing AI rules

There are a few mistakes worth steering clear of when building two-layer rules.

Cramming everything into the company-wide rules

Try to write everything into the company-wide rules and the policy grows long, and tends not to get read on the ground.

What’s more, folding every fine departmental difference into the company-wide rules makes them slow to update. If you only want to change the sales team’s proposal rule but that requires amending the company-wide policy, it won’t keep pace with the work on the ground.

Narrowing the company-wide rules to the baseline and adjusting through departmental rules is the realistic design.

Leaving too much to the departments

Conversely, leaving everything to the departments is dangerous too.

If the criteria drift from one department to the next, you end up with the same information being fine to enter in one department and forbidden in another. That makes it hard for the company as a whole to account for itself.

Departmental rules sit on top of the company-wide ones. A department loosening the standard below the company-wide baseline on its own is to be avoided.

Stopping at the prohibitions

If the AI rules amount to nothing but prohibitions, people on the ground never learn how to use the tools.

You need to show not only “what you mustn’t do” but “what you may use it for” and “how to use it safely”.

Show concrete uses as a set, for instance — a meeting-note template for sales, FAQ-answer rules for HR, a policy-summary prompt for corporate functions — and people on the ground find it easier to act.

No one owning the review

With AI rules, the running of them matters more than the writing.

With no one owning the review, old rules linger on. Outdated material and prompts get used, and prohibitions that no longer fit current work stay on the books.

It’s worth settling a division of responsibility: a cross-functional team — IT, DX, legal, HR — owns the company-wide rules, while each department’s representative owns its departmental ones.

In closing: AI departmental rules separate what to standardise from what to delegate

When designing AI rules that differ by department, what matters most is separating “the part standardised across the company” from “the part adjusted per department”.

What should be standardised company-wide is the baseline the firm must uphold: information that must never be entered, accountability for checking output, account management, incident response.

What should be adjusted per department, on the other hand, is the part bound up with day-to-day work: which tasks may be used, masking methods, who reviews, standard templates, where to turn for advice.

Uniform rules alone leave people on the ground unsure. Leaving it to the departments alone weakens company-wide control. That’s precisely why designing it as two layers — reconciling an overall view with usability on the ground — matters.

Generative-AI rules are not a case of writing them once and being done. They’re something you update little by little, gathering the hesitations, the slip-ups and the success stories that come up on the ground. Start by setting a minimal set of company-wide rules, and begin with a few representative tasks in each department.

Q&A: common questions on departmental AI rules

Which should we build first — the company-wide rules or the departmental ones?

Building the company-wide rules first is the basic approach. Settle the baseline the firm must uphold — information that must never be entered, accountability for checking output, account management, incident response — and then adjust to each department’s practical work. Build the departmental rules first and the criteria tend to drift from one department to the next.

How detailed should departmental rules be?

There’s no need to cover every task from the outset. It’s realistic to begin with three to five tasks that come up often and whose risk is easy to manage. For sales, say, “tidying up meeting notes”, “first cuts of proposals” and “email drafts”; for HR, “training notices”, “policy FAQs” and “structuring interview notes”.

If we mask personal data, is it then fine to enter it into AI?

It’s not something one can say across the board. Even masked, an individual can sometimes be inferred from the context. When handling personal or highly sensitive information, you need to check your internal regulations, the contract terms, the treatment required under data-protection law, and the data-management terms of the AI service you’re using. When the judgement is unclear, make “don’t enter it” the default and check with legal or information security — that’s the safe course.

Won’t varying the rules by department weaken company-wide control?

Build on a foundation of company-wide rules and you can absorb departmental differences without weakening control. What to avoid is a department loosening the company-wide standard on its own. Departmental rules are best framed as making concrete, within the bounds of the company-wide rules, “which tasks it’s used for”, “who checks” and “which information is processed”.

How often should AI rules be reviewed?

Thirty days in at the start, then quarterly, is one illustrative pattern. That said, where there are many users, or many departments handling customer data, personal data or undisclosed information, a shorter cycle may be wiser. In the review, look at the items that drew the most queries, the cases that gave people pause, near misses, and the templates that got used.