Generative tools entered the workplace faster than policies were updated. Staff paste client contracts into a chat window for rewriting, drop draft financial statements in for polishing, and paste code fragments to debug them. In most companies these acts breach no confidentiality undertaking and trigger no alert, because the old rules have nothing to say about them.

By the time a problem surfaces it usually takes one of three forms: a client finds its material elsewhere, a regulator asks about data flows, or a departing employee takes conversation histories with them. A policy written at that point lacks the basis needed to act.

The policy is not about whether AI may be used

Written as a ban, a policy is cheap to enforce and least effective. Staff route around it with phones, personal accounts and browser extensions, and the risk moves from visible to invisible.

A tiered structure keeps use within a manageable perimeter:

TierScopeManagement
PermittedEnterprise model services under a data processing agreementAccounts provisioned centrally, logs retained
RestrictedPublic information summarising, wording, code explanation, meeting notesNo client data or source code; output reviewed
ProhibitedClient personal information, undisclosed transactions, trade secrets, litigation materials, employee dataNo tool, no account, no exception

The test is the data, not the tool. The same model may polish a public press release and may not rewrite a client contract.

Four sections that must be explicit

Data tiers and prohibited inputs. List the prohibited categories directly rather than referring to “sensitive information”. Staff need a checklist they can compare against, not a concept requiring interpretation.

Tool approval. State which tools may be used, who provisions access, and whether a data processing agreement is required. Enterprise services usually undertake not to train on customer data; free personal tiers often give no such commitment, and the difference should be written down.

Output review. Distinguish internal use from external delivery. Internal drafts may be generated; professional conclusions delivered externally must be reviewed by qualified staff with a retained record. Where the conclusion is legal, financial or medical, review cannot be skipped.

Records and audit. Central accounts, retained logs, periodic spot checks. The purpose is not surveillance but the ability to explain data flows when a dispute arises.

Linking the policy to employment rules

Two conditions must be met before the policy can support disciplinary action.

The first is the democratic procedure. Rules affecting employees’ immediate interests must be discussed by the employee representative assembly or all staff, with proposals and opinions, and agreed through equal consultation with the union or employee representatives. Rules on generative tool use affect daily working methods and confidentiality duties, so the procedure applies.

The second is publication. The policy should be publicised by email, intranet and induction training, with acknowledgement or read records retained. A text without evidence of publication is generally insufficient in a dispute.

Both steps are often skipped because they take time. Skipping them reduces the policy to guidance that cannot be enforced.

Three details on external use

Deliverable statements. Where consulting, design or audit deliverables contain generated material, whether and how to disclose it should be settled at contract level and then reflected in project templates.

Client contract restrictions. More client contracts now prohibit AI processing of project materials. These clauses should be identified at inception and passed to the delivery team, rather than discovered before handover.

Content labelling. Published generated content follows the current labelling requirements. Internal use usually does not trigger labelling, but once published the test becomes that of external content.

Rollout sequence

Step one, inventory. Within a week: which teams use which tools, and what data has been entered. Precision is unnecessary; the aim is to find high-risk scenarios.

Step two, lists. Three lists: approved tools, prohibited data, output types requiring review.

Step three, policy. Three to five pages, comparable and actionable. Longer policies tend not to be read.

Step four, training and publication. Train by function, with separate sessions for engineering and sales, where data risk is highest.

Step five, spot checks. Quarterly review of usage logs and review records, with findings fed back into revisions.

Related reading: Employee personal information rules, Employment compliance and contract boundaries, Core contracts for AI companies, Employment compliance service

Frequently Asked Questions↑ Back to article

Do we need a dedicated AI use policy?

Yes. Existing confidentiality and information security rules rarely address generative tools, so an employee pasting client material into a chat window breaches no internal rule and cannot be sanctioned. A policy draws that line.

Is an outright ban simpler?

A ban is cheap but hard to enforce. Staff will use personal accounts and the risk becomes invisible. Tiered authorisation is more workable: approved tools, permitted uses and prohibited data, with use kept within a manageable perimeter.

Which data must never be entered into an external model?

Client personal information, undisclosed transaction and financial data, source code and core algorithms, trade secrets, litigation and negotiation materials, and employee personal information. Once entered, this is an external provision that may breach both data protection and confidentiality duties.

What procedure makes the policy enforceable?

Rules affecting employees' immediate interests must be discussed by the employee representative assembly or all staff, agreed with the union or employee representatives, and publicised. Without that procedure and publication, the policy is difficult to rely on in disciplinary proceedings.

What should we watch when staff deliver AI-assisted work externally?

Professional conclusions require human review with a retained record; generated content in external deliverables follows the labelling rules; and where client contracts prohibit AI processing, that restriction should be identified at project inception.

How long does implementation take?

The policy text can be drafted within two weeks; the approved tool list, training and spot checks usually take a month. Multi-site organisations need to phase publication and training.

Geason Law Offices AI Industry Research Group | Reviewed by Ho Qianggao