Rules for using AI coding and writing tools at work: what to allow and what to protect

A developer at a software services firm is stuck on a failing integration late in the evening. She pastes a block of the client's code, including a config file with a service address, into a public chatbot and gets a fix in seconds. Nobody told her not to. Nobody told her what was fine either.

Most teams are in this position. Tools arrived faster than rules. This post helps you write rules that people will follow, in an afternoon, without pretending to be a lawyer.

Before you write anything, ask. A short anonymous form works: which tools do you use, for what tasks, and what do you paste in? Do not use the answers to punish anyone. You want an honest picture of drafting emails, writing tests, explaining old code, summarising meeting notes and generating documentation, so the rules cover real use.

• Open: public material, your own marketing copy, generic coding questions with no client or company detail, and open source snippets.
• Restricted: your internal code, internal documents and plans. Allowed only in tools the company has approved and configured.
• Never: client data, client code under contract, credentials, keys, personal information of staff or users, and anything marked confidential.

Your contracts may already say what you can do with client material. Read them, and ask your own qualified legal adviser how those clauses apply to AI tools. In software development companies this check matters most, as many client agreements were written before these tools existed.

A rule that says use good judgement is not a rule. Keep a one-page list of approved tools, who may use each, and under which account. Prefer company-managed logins, so that you can see usage and remove access when someone leaves. Ask each vendor in writing how they treat prompts and uploaded files, and whether your content can be used to train their models. Record the answers with the date.

1. 1

   Collect current use

   Run the short form and a ten-minute talk in the next team meeting.

2. 2

   Draft the three groups

   Adapt the lists above to your clients and products. Let two senior engineers and one delivery lead review them.

3. 3

   Pick approved tools

   Name each tool, the account type, the data group it may touch and a person who owns it.

4. 4

   Write the review rule

   State that a named person must read and test anything produced by a tool before it goes into client work.

5. 5

   Publish and brief

   Add a section to your IT and internet usage policy, run a short session with examples, and ask people to confirm they have read it.

6. 6

   Review in three months

   Tools change quickly. Set a calendar date to revisit the list and the groups.

• Generated code goes through the same review and testing as any other code.
• The engineer who commits the code owns it, whatever tool wrote it.
• Do not paste secrets, tokens or internal addresses into prompts. Use placeholders.
• Check licence terms before pulling in larger generated blocks that look copied from a known project.
• Say in the pull request when a substantial part was tool-generated, if the client or your own standards ask for it.

Writing tools are common in proposals, job posts, emails and reports. The risks are different. Output can sound confident and be wrong. It can repeat another firm's text. It can invent a case study or a client name. Set one firm rule: nobody sends a draft to a client or posts it publicly without a named person reading every line and checking each fact.

Purpose: to use AI tools safely while protecting clients, staff and the company.
Approved tools: list name, owner, account type and data group allowed.
Never paste: client data, credentials, personal information, anything marked confidential.
Review: a named person reads and tests all output before client use.
Disclosure: tell the client when their contract or your standards ask for it.
Reporting: if something sensitive was pasted by mistake, tell the tech lead the same day.
Owner and review date of this sheet.

Someone will paste the wrong thing. If reporting leads to a public telling-off, the next person will hide it. Set a no-blame rule for prompt reporting, with a simple route: tell the tech lead, note what was pasted and where, and let the company decide the next step with its adviser. Repeated or deliberate breaches belong in your normal conduct process, covered in our IT and internet usage policy support.

A one-hour session with real examples beats a ten-page document. Show a good prompt with placeholders and a bad prompt with a client file. Show a generated function with a subtle bug. Pair this with learning time, as in our piece on upskilling a services team for AI work. If analysts in your firm work on client datasets, the companion note on handling client data in analytics projects applies as well.