How Can You Write Practical AI Use Rules for Yourself or a Small Team?

Short answer

Write rules that answer decisions at the moment of work, not abstract aspirations. At minimum, specify permitted uses, data that must not be entered, output requiring verification, whether AI may send, pay or edit, who approves high-risk work, which records are required, and how to stop, report and remedy error. Keep the core short enough to be used, concrete enough for real cases, and review it as tools, models and work change.

Start from real tasks, not “use AI responsibly”

Responsible, transparent and fair AI is a sound direction, but it does not tell an employee whether a client contract can be uploaded, AI may draft performance feedback, or an agent can answer external email. Rules need verbs and objects: summarise a public report, rewrite an internal draft, analyse de-identified data, suggest code, send a customer message, change access.

List ten to twenty tasks the team used or considered in the last month. For each, note data, affected people, purpose, consequence of error, verification and whether external state changes. Build boundaries around these tasks rather than copying a generic policy from a large institution.

Australian Government AI adoption foundations recommend accountability, context and impact understanding, risk management and continuing review. A small team can implement the same logic in a proportionate form. Australian Government: Guidance for AI Adoption—Foundations

Part one: define permitted, approval-required and prohibited uses

Three categories are clearer than long prose. Green uses are allowed in approved tools: brainstorming from public information, low-risk internal drafts, formatting and personal learning. Yellow uses require a named approval or additional controls: customer content, unpublished business material, hiring assistance, professional-advice drafts and shared-file edits.

Red uses are prohibited: entering passwords and complete identity records, using a general AI to make final medical or legal decisions, unapproved autonomous payment, bulk deletion, covert employee surveillance, deceptive impersonation material, or processing files a contract forbids sharing.

Classify the combination of use, data and action. Permission to draft public copy does not grant customer-database access. Provide boundary examples and a fast route for questions.

Part two: establish explicit data red lines

List data excluded from AI services without exceptional approval: passwords, keys, payment credentials, full identity evidence, health information, privileged legal material, client secrets, unpublished financial and transaction information, secrets in source code, contract-restricted content and identifiable employee matters. Add industry-specific categories.

State the controlled conditions under which internal or confidential data may be used: approved enterprise account, named workspace, minimum fields, de-identification, data-processing terms, access logs and deletion date. “Do not upload sensitive information” leaves every person to define sensitivity.

Require checks of hidden metadata, comments, attachments and shared-link scope. Output retains the input classification; a shorter AI summary does not become public.

Part three: specify verification by claim and consequence

Avoid “all output must be human reviewed,” which can mean a quick skim. Name the checks: facts against independent sources, citations opened and matched to claims, figures recalculated, professional conclusions reviewed by competent people, and decisions or actions reconciled to original records.

Low-risk prose may be read by the author or sampled. Public, customer, financial, legal, safety and health material needs stronger checks. Where evidence is insufficient, staff should stop rather than let a model's complete tone fill the gap.

Label AI output draft until a defined state is reached. State who can change draft to approved and which evidence they must see.

Part four: separate generation and execution permission

List actions AI may not perform independently: external sending, public publication, payment, signature, privilege change, bulk deletion, production deployment and decisions affecting a person's rights. AI can prepare a proposal; an authorised person approves the complete target, content and consequence.

For permitted low-risk automation, impose value, volume, directory, recipient or environment limits, plus activity records and reversal. “Be careful” in a prompt is not a technical control. Enforce authority through accounts, code and tool configuration.

Text from email, web pages and files cannot expand an agent's permissions. New connectors and additional access need fresh approval.

Part five: assign roles instead of saying “users are responsible”

A small team needs at least a business owner and a tool/data administrator. One person may wear both hats, but the duties remain explicit. The business owner approves use, risk and final outcome. The administrator manages accounts, provider, permissions, versions and logs. Content authors verify output. Qualified people decide professional issues. Everyone knows how to report a problem.

The provider belongs in the responsibility chain but cannot take ownership of the team's final use. Record who reviews service terms, data handling, retention and update notices. If nobody can evaluate a high-risk feature, do not adopt that feature.

Do not put every obligation on the junior employee who clicks Send. Approvers need evidence and veto; the organisation supplies reasonable workload and training.

Part six: set the minimum record

For ordinary low-risk work, final version and primary sources may suffice. For customer or public material, add service/model time, input scope, raw output or differences, material verification and approval. For high-risk action, retain tool parameters, permissions, execution receipts and incident logs.

Specify where records live, retention, access and deletion. Do not copy sensitive input into uncontrolled logs, but do not remove every trace for convenience.

Use a stable template: task, data class, AI service, sources, material changes, verification, approval and release date. The shorter and more integrated the form, the more likely people are to complete it.

Part seven: prepare stopping and incident response

Everybody should know immediate stop signals: suspected sensitive-data disclosure, wrong external sending, anomalous payment, sudden model behaviour change, malicious instructions in a file, excessive permissions, inability to confirm a critical source or one repeating error across a batch.

Provide one reporting route and owner. The first response usually contains continuing impact and preserves necessary evidence rather than quietly deleting. Then identify affected objects, correct or notify, revoke access, contact the provider, and meet applicable legal and contractual obligations.

Protect good-faith reporting. Fear of punishment delays recognition and enlarges harm. Distinguish honest mistake, inadequate training and deliberate violation.

Part eight: govern new tools and model updates

Approval of one product does not approve every later connector, memory feature and agent capability. New features change data, permissions and action. Name who tests and approves them, which versions may enter formal work, and how to roll back.

Run representative tasks including boundaries, sensitive data, hostile input and past errors. Observe accuracy, citations, structure, refusal, authority, cost and human amendment. A generally stronger update still needs local verification.

Review rules at least quarterly or after a major update, incident, legal change or new business use. Preserve a version and effective date and communicate material changes.

How to structure a one-page core

Put only in-the-moment decisions on the first page: green/yellow/red uses, data red lines, mandatory checks, prohibited autonomous actions and the reporting route. A second page or appendix can contain provider lists, detailed procedures, checklists and owners.

Use “if–then–owner.” For example: “If a file contains customer personal information, use only the minimum necessary passage in the approved enterprise workspace; the project owner approves.” Or: “If output will be public, the author verifies every fact and citation; the editor approves the final version.”

Avoid undefined terms. If a rule says high risk, list health, safety, rights, livelihood, substantial money, sensitive data, scale and irreversibility. Readers should not repeatedly guess what the policy author meant.

Use a decision tree for uncertain cases

First: Is AI needed, or would a simpler tool work? Second: Does input include non-public, personal or restricted data? Third: Who is affected by error, and can it be reversed? Fourth: Does AI only advise, or can it act? Fifth: Who can verify and approve?

If an answer is unavailable, stay in draft or sandbox and escalate. Do not interpret absence of a prohibition as permission. At the same time, make the question route fast enough that employees do not route around it.

A rotating AI owner might answer ordinary yellow cases within one working day while high-risk use enters formal review. A small team does not need a committee for every email, but somebody must own boundary judgement.

Train with real errors, not policy recital

Show an invented citation, a rewrite that changes meaning, an agent influenced by hidden instruction, and a document containing concealed comments. Have the team practise classifying, verifying, refusing and reporting. Concrete cases change behaviour more than “AI may make mistakes.”

Roles need different depth. General users learn data and verification; approvers learn risk and evidence; administrators learn permissions, logs and providers; developers learn tool boundaries, evaluation and stopping. Completion of one training session is not permanent competence.

Keep a short checklist and approval template beside the rule so compliance does not rely on memory.

Use a few measures to learn whether the rules work

Track approved uses, time to resolve yellow cases, completion of critical checks, sensitive incidents, escaped errors, human rework and questions raised. A rise in questions can be a healthy early signal that people recognise boundaries.

Do not reward a team simply for using more AI, and do not interpret zero incidents as proof of safety. Zero reporting may reflect confusion or fear. Sample real work and records and ask which rules are hardest to follow.

The NIST AI Risk Management Framework provides a cycle across govern, map, measure and manage. A small team need not reproduce every structure, but can follow the cycle: assign accountability, understand the use, test evidence, treat risk and update from the result. NIST AI Risk Management Framework

Move the rules into tools and workflows

Make approved accounts the only accounts available; disable unnecessary training or sharing; limit connectors; default output to draft; show recipients before sending; cap payment; and record required events automatically. Technical defaults reduce reliance on individual willpower.

Put source and review fields into content templates, AI use into project kickoff, data and version questions into procurement, and AI trajectories into incident response. Integration with existing work is more effective than a new portal nobody opens.

Leaders must follow the rules too. An executive uploading a confidential file through a personal account will undermine the norm faster than any training can establish it.

My assessment: the best rule makes “I don't know” safe

In a rush to adopt, teams try to force every case into allowed or prohibited. A robust rule preserves pause, question and task reduction—and does not treat them as resistance to innovation.

The value of the rule is not prediction of every AI feature. It supplies stable questions for new situations: What is the data? Who is affected? What is the consequence? How is it verified? Who controls action? What is the remedy? Those questions survive product change.

One-page core checklist

• Is this use permitted, approval-required or prohibited?
• Does input contain personal, confidential, privileged, credential or contract-restricted material?
• Is only minimum data used through an approved account, device and workspace?
• Who verifies facts, citations, figures, professional judgement and final action, and how?
• Is AI limited to drafting, with sending, payment, deletion and publication separately approved?
• Which sources, versions, changes, approvals and execution records must be retained?
• How does a person stop and whom do they contact after disclosure, anomalous behaviour or unverifiable claims?
• Who retests and updates the rules after tool, model or use changes?

Conclusion

Effective personal or small-team AI rules turn abstract responsibility into work decisions: which uses, which data, what verification, who can execute, what to preserve and how to remedy. Keep the core page brief, put detailed process in an appendix, and implement defaults through permissions and templates. The goal is not to stop AI use. It is to make clear when the team can move quickly, when it must slow down, and who can responsibly make the final decision.

Related questions

• Which Tasks Should You Give to AI, and Which Should You Keep?
• Who Is Responsible When AI Causes Loss?

Continue reading: All articles in How Far Should You Trust AI?