Setting the Rules for Employee AI Use: A Governance Starting Point

What this starting point covers

The rules cover people using AI tools in company work. That includes standalone assistants, AI features inside software you already use, transcription tools and browser extensions.

Decide whether the rules also apply to contractors, freelancers or advisers who do work for you. An internal policy does not automatically bind a supplier. If you want it to apply to them, their contract or engagement terms need to say so.

The rules do not cover:

• Building AI into your products.
• Automated decisions about customers.
• Using AI to evaluate people.

Each of those needs a broader assessment with technical and legal input.

Employee AI use carries several distinct risks. NIST's generative-AI risk profile, a voluntary US framework, treats them separately (NIST AI 600-1). Among them are:

• Confidently stated false content.
• Data privacy.
• Over-reliance on automated output.
• Information security.

A rule that looks only at what goes into a tool addresses one of these. The rules below therefore check the activity, the tool, the information, what the tool may do by itself, and how the output is reviewed.

Step 1: Find out how AI is already used

Explain to each team that the inventory exists to set workable rules, then ask what they use and how. For each use, record:

• Tool and account: for example, a general AI assistant on a personal free account.
• Connected to: email, files, calendars or other systems the tool can reach.
• Who uses it, and what for: the team and the task.
• Information that goes in: the categories in Step 4.
• Where the output goes: internal use, or out of the company.
• Whether the tool takes actions itself: for example, sending messages or updating records.

Include personal accounts used for work and AI features switched on inside other software. An inventory records what people report. It does not prove it is complete, so repeat it at each review and whenever a new tool is proposed.

Step 2: Assign responsibilities

The role assignments below are an illustrative model. Adapt them to your existing governance and delegation-of-authority matrix.

• Owner or general manager

  In this model

  Approves the rules. Approves uses involving Restricted information.

• Policy owner (a named manager)

  In this model

  Keeps the inventory and the approved-use register. Takes requests through review. Approves uses up to the Internal category. Receives reports of mistakes. Runs the periodic review.

• Technical reviewer (someone with IT responsibility, or an external adviser)

  In this model

  Reviews tools, accounts, settings, connections and any tool actions before approval.

• Qualified adviser

  In this model

  Reviews contractual and privacy questions for uses involving personal or confidential information.

• Person responsible for each client relationship

  In this model

  Confirms what that client's contract and instructions say.

Another appropriately authorised role can take the approval decisions instead. Some safeguards should hold within this proposed policy whoever holds the roles:

• Uses are approved before they start.
• Each new use gets technical review.
• Personal or confidential information gets contractual and privacy review.
• No approval permits what a law, contract or client instruction prohibits.

Step 3: Approve uses, not just tools

Approving a tool in general says little about what people will do with it. Instead, record each approved use in a register. Each entry states:

• The activity: for example, "drafting marketing content".
• The tool and specific account: named, not a category.
• Who may use it: the named team or role.
• The highest information category allowed: from Step 4. For Restricted information, the entry also names the specific types allowed.
• Any actions the tool may take by itself: the default is none.
• Conditions and an expiry date: conditions might include settings that must stay in place.

Once a use is approved, people can work within it without asking permission for each task. Anything outside an entry — a different activity, account, information type or action — needs approval first, even if the information is public.

Approval. Requests go to the policy owner.

• Technical review (every request): the technical reviewer checks:
  • whether the account is company-managed
  • the vendor's terms and settings on training use, retention and access (these differ between plans and can change)
  • what the tool can reach
  • whether those permissions are needed for the activity
• Contractual and privacy review (personal or confidential information): a qualified adviser reviews the position, and the person responsible for any affected client relationship confirms what the contract and instructions say.
• Decision: the decision is made by the role with authority for that category.

Approvals and refusals are both recorded.

UK guidance illustrates why the tool checks matter. The National Cyber Security Centre notes that information given to consumer AI services may be stored, retained or used to improve the service unless specific privacy controls are in place. It also notes that a compromised AI agent can expose whatever the agent has access to (NCSC).

Tools that act. In this starting point, a tool may draft, summarise or suggest. Any action the tool takes by itself — sending messages or invitations, changing records inside or outside the company, or reaching further systems — is excluded unless the register entry explicitly approves that action after technical review. Reviewing a tool's output is not the same as authorising it to act.

When approval lapses. Permission for a use ends when either of these happens:

• Its expiry date passes.
• One of its conditions stops being met, for example:
  • a setting is changed
  • a new connection is added
  • the vendor changes relevant terms

People must then stop that use. Anyone who becomes aware of a change tells the policy owner. The policy owner arranges renewal, or removal of access.

Unless you have set up a technical control, nothing stops the tool working at expiry. The rule relies on people stopping, and on the policy owner acting on renewal dates.

Step 4: Classify the information

The definitions below are illustrative, so adapt them to your business.

• Public: information that has been published, by your company or others, and is neither personal information nor held in confidence. Examples: your published product details, or an official summary of a standard. Drafts approved for publication stay Internal until they are published.
• Internal: your company's non-public information that is not personal, not held in confidence and not Prohibited.
• Restricted: information needing specific approval, including:
  • personal information about anyone, including personal information that is publicly available elsewhere
  • information received in confidence from clients or partners
  • bank or payment details
  • unannounced bids and pricing
  • legal matters
• Prohibited: live passwords, authentication codes and tokens, private keys and similar credentials. These are never entered into an AI tool, and no approval can permit it.

Four rules apply:

• Information may be used only up to the category, and for Restricted information only the types, named in the register entry.
• Where content mixes categories, the most restrictive applies.
• Public availability does not remove Restricted status from personal information or from information held in confidence.
• If you remove passages to lower the category, reclassify what remains. Remaining details can still reveal a client's plans or identify a person.

Step 5: Check the output, and keep a boundary on decisions about people

AI output can be fluent and still wrong, and people can rely on it more than it deserves. The level of checking depends on where the output goes:

• Internal working use: the person using the tool checks the output before relying on it.
• Output that leaves the company or supports a financial or contractual decision: the person accountable for that work reviews it first, checking facts, figures, names, references and calculations against the sources. They are responsible for the content as if they had written it.

A sign-off record shows that a review took place, not that it was thorough. The periodic review looks at a sample.

Decisions about people.

• Administrative uses can be approved: for example:
  • drafting a job advertisement from approved content
  • drafting interview invitations that a person checks and sends
• Evaluative uses are outside this starting point: for example:
  • ranking, scoring, screening or shortlisting candidates
  • assessing performance
  • recommending decisions on pay, discipline or dismissal

This applies even if a person makes the final decision. Some jurisdictions have specific rules on automated decisions about people, so treat any such use as a separate project with legal and technical input.

When something goes wrong

Mistakes follow a separate route. Examples include entering Prohibited or Restricted information, using an unapproved tool, or letting a tool take an unapproved action.

The employee:

1. Stops further sharing.
2. Tells the policy owner promptly.
3. Does not delete history, change settings or close the account unless asked. Those steps can remove information needed to understand what happened.

The policy owner:

1. Contains the incident: for example, suspends the tool's access to company systems.
2. Records securely: what was entered, when, through which account and who is affected.
3. Takes technical and, where relevant, privacy advice: before anything is deleted. Deleting visible history does not show that the provider has erased every copy.
4. Decides on that advice: whether anyone must be informed.
5. Considers: whether the rules, approved uses or training need to change.

If credentials were entered, the technical reviewer also advises on changing them.

Say in the rules that prompt reporting is expected, and explain how reports will be handled.

An illustrative acceptable-use statement

Three worked examples

These concern a fictional company. They illustrate the rules and do not describe a Darwish & Co. client or engagement.

A social media post. The register has one entry:

• Activity: drafting marketing content.
• Tool and account: a company-managed AI assistant account.
• Who: the marketing team.
• Information: up to Internal.
• Tool actions: none.
• Validity: expiry date not yet reached, conditions met.

A marketing coordinator drafts a post from product details already on the company website. The checks run in order:

1. Activity: drafting marketing content, which the entry covers.
2. Tool and account: the listed company account.
3. Information: Public, which is within Internal.
4. Approval: still valid.
5. Actions: the assistant offers to publish directly through a connected social account. The entry approves no actions, so she declines.
6. Output review: the post leaves the company, so the marketing lead reviews it before she publishes it herself.

Result: permitted, as described.

Meeting notes with a client's confidential plans. An account manager wants to use the same account to summarise notes that mix internal follow-up actions with a client's unannounced expansion plans, shared under a confidentiality agreement.

1. Activity: summarising client meeting notes. The only entry covers drafting marketing content, so this is not approved, and the check stops here.
2. For completeness, the information also fails: the notes are Restricted, beyond the entry's Internal limit.

Removing the confidential passages would fix neither problem:

• The activity would still be unapproved.
• One remaining action — "prepare a quotation for the client's new site" — still reveals the plans.

Result: the account manager writes the summary without AI. If such summaries are needed regularly, the policy owner can start a request for a specific use. That request needs technical review, the client relationship owner's check of the agreement, contractual and privacy review, and a decision by the role authorised for Restricted information.

CVs in a personal account. An HR assistant has pasted candidate CVs into a personal AI account to produce a shortlist.

1. Activity: shortlisting is evaluative, so it is outside the rules.
2. Tool and account: a personal account is not in the register.
3. Information: CVs contain personal information, which is Restricted.

This is a mistake, so the incident route applies:

1. The assistant stops, tells the policy owner as soon as she realises, and leaves the account as it is.
2. The policy owner records what happened.
3. The policy owner takes technical and privacy advice before anything is deleted, and decides on that advice whether anyone must be informed.
4. The HR manager shortlists without using the AI output.

Follow-up: the review then considers whether an administrative use, such as drafting interview invitations, should be approved. Screening remains outside scope.

Keep it under review

At each review, the policy owner:

• Updates the inventory.
• Checks each entry's settings, connections and expiry date.
• Renews or removes entries.
• Samples reviewed outputs.
• Reports incidents and proposed changes for approval.

A signed acknowledgement shows that people received the rules, not that they follow them. The review is where you find out what actually happens.

Where this fits

These rules give you a defined starting point:

• You know how AI is used.
• You know who is responsible.
• You know which uses are approved, with what information and what actions.
• You know who checks the results.
• You know what is out of scope.

They are not an AI management system. ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. It is intended for organisations that develop, provide or use AI-based products or services (ISO). The rules above can feed into such a system. Adopting them does not amount to conformity with the standard or to certification.

Plan a broader assessment, with technical and legal input, if you want AI to evaluate people, shape decisions about customers, act across your systems beyond narrowly approved actions, or form part of what you sell.