AI Code of Conduct: A Practical Template for Your Team

An AI code of conduct is a short set of expectations for how people in your team use AI. It should say what information is allowed, what must be disclosed, who checks results, and who is responsible when something goes wrong. The template below gives you a starting point to adapt and approve.

fenbs can keep the approved rules and the human decisions behind them in the context connected assistants read. Start with a code people can follow on an ordinary workday, then add the instructions your actual tasks require.

What should this code cover?

Cover behavior people can recognize: choosing a permitted tool, checking what they upload, reviewing a draft, and asking for help before an uncertain action. Include employees, contractors, and others within the scope you choose. Name a person who maintains the code and a route for questions.

Use separate task instructions for detailed acceptance criteria. A general code should not attempt to describe every test for a financial report, a marketing image, and a software change. It should require the relevant review and tell the person where to find it.

The GAO AI accountability framework↗ (opens in a new tab) highlights governance, data, performance, and monitoring. Those are useful coverage checks for your draft. The wider AI governance library covers related issues; this page provides wording a team can adapt.

What can you copy into a first draft?

Replace the bracketed fields before approval. Remove permissions that do not fit your team and add a reference to the actual approved tool list. The wording is a starting point for a person’s review, not a claim that the same policy suits every organization.

AI CODE OF CONDUCT
Owner: [person or role]
Approved by: [authorized person]
Applies to: [people, work, and systems]
Effective date: [date]
Review date: [date]
Questions and incidents: [contact route]

1. Purpose and limits
Use AI only for [approved purposes] through [approved tools/accounts].
Do not expand a task into an action affecting others without approval.
People remain responsible for work produced with AI assistance.

2. Data and source material
Use only information permitted under [data-handling instructions].
Do not enter credentials or unapproved personal, customer, or confidential data.
Check attachments and connected sources as well as typed prompts.
Use source material only when authorized for the intended purpose.

3. Review and accuracy
Treat generated output as a draft until required checks are complete.
Verify consequential facts, calculations, citations, and permissions.
Use [task-specific review instructions] and name the responsible reviewer.
Do not present an unchecked result as verified or approved.

4. Disclosure and attribution
Follow [audience-specific disclosure rules] when AI contributes to work.
Describe the assistance accurately and preserve required source attribution.
Do not fabricate evidence, quotations, identities, or approval records.

5. People and decisions
Check for harmful treatment, exclusion, or misleading representation.
Keep required decisions and sign-off with an authorized person.
Provide [human contact or correction route] for affected people.

6. Problems and exceptions
Pause when a data boundary, review condition, or approval is uncertain.
Report mistakes through [contact route] and preserve permitted evidence.
Only [authorized role] may approve an exception and record its limits.
Use [manual fallback] while the issue is unresolved.

7. Records and maintenance
Keep required records in [approved location] under [retention instructions].
Record approved changes, their reasons, and the person who approved them.
Review this code after incidents or material changes to tools or work.

Read the filled-in version aloud using a task someone did yesterday. Can that person identify the permitted input, required review, and contact for uncertainty? If a sentence needs a lengthy explanation, give it an example or move the detail to a linked task instruction.

This code concerns conduct when using AI, including writing, analysis, and design. Selecting software is a separate question covered by no-code AI tools. Do not let a discussion about which app to buy replace the decision about acceptable behavior.

How should you adapt the data and disclosure rules?

Replace “sensitive data” with categories your team understands and a route for uncertain cases. For example, a hypothetical design studio could permit public product descriptions but require approval before using unpublished client plans. Say which account and tool the permission applies to; permission in one place does not establish permission everywhere.

Specify disclosure by audience and task. An internal brainstorming note may need a different record from an external deliverable. The code should point to the approved expectation, including who answers questions. Avoid vague wording that leaves employees to guess what a client, instructor, or reviewer expects.

Also choose what evidence belongs in the work record. Keep source references and a concise description of the assistance where allowed. Follow your organization’s retention rules instead of collecting every conversation automatically. Sharing a prompt can itself expose the information the policy was written to protect.

What does meaningful human review require?

Name the reviewer and the checks that matter before anyone relies on the result. The reviewer needs relevant knowledge and permission to reject the output. “A human has seen it” is a weak condition if that person cannot inspect the source, reproduce a calculation, or request changes.

For developers, the code can require ordinary change review plus the checks described in reviewing AI-generated code. AI code review tools may support that work, but a generated review does not by itself establish acceptance. Keep the person’s approval separate from an assistant’s recommendation.

Write down what happens when a check fails. The person should know whether to revise, seek specialist help, or stop the task. Save approved review boundaries in fenbs Decisions and rules so another assistant does not interpret a polished draft as an approved result.

How do you introduce the code without making it shelfware?

Test it with a small group before making it the normal process. Ask each person to handle a permitted task, an uncertain upload, and an output with a bad citation. Observe whether the code helps them make the next choice. Revise the wording when the answer depends on information they cannot find.

Give the owner time to answer questions and review proposed changes. Encourage people to report near misses, including times they paused successfully. Make the manual route usable so the instruction to stop is realistic when a deadline is close.

Use a brief practice exercise during onboarding. Ask a new teammate to find the current code, explain one prohibited input, and identify who approves an uncertain use. If they find two conflicting versions, resolve the conflict before asking them to follow either one. Keep the approved version easy to locate and explain how changes will reach people who already completed onboarding.

The NIST AI RMF Playbook↗ (opens in a new tab) offers suggestions to adapt to the setting rather than a universal checklist. Apply the same discipline to this template: evaluate it against the team’s work instead of treating completed fields as proof that the process works.

How to do this with fenbs

1. Create a free account and add a project for the team’s AI-assisted work. Choose a team kanban board when colleagues need access.
2. Have the authorized person review the adapted code. Record their approved continuing instructions in Decisions and rules, including scope and reasoning.
3. Create tasks for missing tool reviews, training examples, or unanswered policy questions. Keep proposed instructions distinct from decided rules.
4. Use the integration guides to connect a supported assistant. Ask it to read the project context before starting a task.
5. Record lessons from the trial and save progress. Have a person approve replacements when an existing instruction needs to change.

fenbs is free for one person, no credit card. It does not inspect every prompt or enforce a company’s data policy inside other apps. An AI brain retains the approved work context; use technical controls and specialist review where the task requires them.

When should you update the code?

Set a review date and revisit the code when tools, access, tasks, or audience expectations change. Record the reason for each approved replacement. A narrow exception should state its limits so it does not quietly become permission for unrelated work.

After an incident, ask which instruction or supporting process would have changed the outcome. Avoid adding a rule merely to make the document longer. Keep the current instruction easy to find, with the earlier reasoning retained in the history of the work.