I work as a technology and privacy lawyer for Canadian SaaS companies and professional service firms with roughly 40 to 300 employees. Much of my recent work involves turning informal AI habits into clear rules that staff can understand during an ordinary workday. I have reviewed policies that were so restrictive nobody followed them, as well as policies so vague that employees could not tell whether pasting client information into a chatbot was permitted. The policy has to be usable.
Why a General Ban Usually Solves the Wrong Problem
My first step is rarely drafting. I begin by asking employees which AI tools they already use, what information they enter, and what they do with the output. During one review last spring, a management team believed only 3 people were experimenting with generative AI, while interviews showed that staff across marketing, customer support, software development, and finance had already adopted several tools.
A complete ban may sound safe, but it often pushes AI activity out of sight. Employees create personal accounts, use free versions of tools, and avoid reporting mistakes because they know the activity was prohibited. I would rather give people an approved path with defined boundaries than pretend a new working method can be removed through a single sentence in a handbook.
I usually separate AI uses into practical categories instead of treating every system as equal. A spelling assistant that receives a short marketing paragraph presents different concerns from a tool that processes medical records, legal instructions, source code, or customer financial data. My policies account for the information entered, the purpose of the task, the system being used, and the consequences if the output is wrong.
That distinction matters. An employee may be allowed to ask an approved system to suggest 10 headings for a public blog post, while being prohibited from uploading an unpublished contract from a client. Clear examples reduce debates because employees can compare their proposed use with situations that resemble their actual work.
Deciding When AI Use Must Be Disclosed
Disclosure rules require more care than many policy templates suggest. I do not advise clients to label every email that received minor grammar assistance from an AI tool, since constant notices can become meaningless. I focus disclosure requirements on situations where a reasonable recipient would care that AI materially influenced the work, analysis, recommendation, image, decision, or communication.
For businesses developing their first policy, I sometimes use external legal resources to compare approaches and identify missing issues. A resource discussing AI Use and DIsclosure POlicies can help a company recognize that internal permission rules and external disclosure duties should be considered together. I still tailor every clause to the company’s services, contracts, risk profile, and actual use of AI.
In client-facing work, I often recommend disclosure when AI generates a meaningful part of a report, evaluates personal information, produces professional advice, or contributes to a decision affecting someone’s rights or access to a service. The notice should explain enough for the recipient to understand the role of the system. A vague statement such as “technology may be used” rarely answers the question a client is actually asking.
A useful notice can be one or 2 sentences. It might state that an approved generative AI tool assisted with an initial draft, while a qualified employee reviewed and accepted responsibility for the final document. That wording identifies the function of the tool without suggesting that the machine replaced professional judgment.
I also build disclosure triggers around errors and incidents. If an employee learns that AI-generated content sent to a client contains a serious factual mistake, the policy should explain who must be contacted and how quickly. For a high-risk service, I may recommend internal escalation within 24 hours rather than leaving the employee to decide whether the problem is significant enough to mention.
What I Put Inside the Acceptable Use Rules
The central section of my policy describes permitted, restricted, and prohibited activity in plain language. I name approved systems where possible, because telling staff to use “secure AI” leaves too much room for interpretation. The document also states whether employees may create personal accounts, enable model training, install browser extensions, connect workplace drives, or upload files.
Confidential information receives its own treatment. I define it through familiar examples such as customer records, pricing terms, employee files, passwords, unpublished financial results, private legal advice, and source code. A policy becomes easier to apply when people can recognize the information instead of interpreting a broad legal definition during a busy afternoon.
I normally prohibit entering confidential or personal information into a public AI service unless the company has approved the system and the specific use. Approval may depend on contractual protections, retention settings, access controls, data location, deletion rights, and whether prompts are used to train the provider’s models. A paid account does not automatically answer those questions.
Human review must be described as a real process rather than a slogan. I state that the reviewer should check factual accuracy, source reliability, confidentiality, bias, contractual limits, and whether the output matches the assigned purpose. For software code, the review may also include security testing and licence checks before anything reaches production.
I do not write that employees must “verify everything” without explaining what verification means. A customer support employee may need to compare an AI-generated answer with the current refund policy, while an accountant may need to recalculate every figure using the source records. Different work needs different checks.
Assigning Responsibility Without Creating Confusion
Many early AI policies fail because they assign responsibility to everyone and no one. I identify who approves tools, who evaluates privacy and security, who answers employee questions, and who manages incidents. In a company with fewer than 100 employees, those functions may sit with 2 or 3 people rather than separate departments.
The final user of the output usually remains responsible for the work. An employee cannot avoid accountability by saying that a chatbot produced the statement, calculation, image, or recommendation. The policy should make that point directly, especially in legal, health, financial, engineering, and other work where an error can create serious harm.
Managers also need duties. They should not pressure staff to use AI for sensitive work before an approved process exists, and they should not treat faster production as proof that quality controls are unnecessary. I have seen teams cut a drafting task from several hours to less than one hour, then lose the saved time because nobody checked the citations, names, or figures.
Senior leadership owns the risk created by company incentives. If performance targets reward speed while review work is ignored, employees will eventually skip the checks described in the policy. Good governance connects the written rules with staffing, deadlines, training, procurement, and supervision.
I apply the same discipline to organizations with very different public profiles. If I were reviewing a policy for a firm with the visibility of Moseley Collins, APC, I would pay close attention to confidentiality, professional judgment, client communications, and the risk of an AI output being mistaken for verified legal analysis. The organization’s real practices would still determine the final wording.
Handling Client Consent, Contracts, and Vendor Terms
Disclosure and consent are related, but they are not interchangeable. A company may need to tell a client that AI is being used even when formal consent is not legally required. In other circumstances, a contract, professional duty, privacy requirement, or client instruction may mean the company must obtain permission before using the system.
I review existing customer agreements before finalizing the policy. Some contracts restrict subcontractors, offshore processing, automated decision-making, data transfers, or the use of confidential material for system improvement. An AI provider may fit within one of those clauses even if the agreement never uses the term artificial intelligence.
Vendor terms deserve equal attention. I look for retention periods, model-training provisions, security promises, audit rights, ownership clauses, liability limits, and the provider’s ability to change terms. One client discovered during procurement that a tool could retain submitted content longer than the team expected, which changed the proposed use from general drafting to public information only.
The policy should also address client objections. Staff need a clear method for recording that a customer has declined AI-assisted work or imposed special limits. A note hidden inside one email thread is not enough if 6 employees may later work on the same account.
Training, Records, and Policy Maintenance
I treat the launch of the policy as the start of the work. A 12-page document placed in a shared folder will not change behaviour by itself. Employees need short training built around the systems and tasks they use, including examples of permitted prompts, prohibited information, review steps, and incident reporting.
Training should include uncomfortable examples. I often show how a confident AI answer can contain a false case name, an invented product feature, or a calculation that appears correct until someone checks the inputs. Seeing a realistic failure helps employees understand why review is part of the task rather than an optional administrative step.
Record keeping should match the level of risk. A company may not need to preserve every prompt used to polish public marketing text, but it may need a record of AI involvement in a significant assessment, customer decision, or regulated service. I define who keeps the record, what it contains, where it is stored, and how long it remains available.
I usually recommend reviewing the policy at least every 6 months during the first year. Approved tools change their terms, employees find new uses, and regulators or courts may clarify expectations. A version number and approval date help staff confirm that they are reading the current document.
Feedback matters too. I ask employees which rules are unclear and which approval steps cause them to use unofficial workarounds. A practical revision based on 20 real questions often improves a policy more than another page of abstract legal language.
I judge an AI use and disclosure policy by what happens on an ordinary Tuesday when an employee has a deadline, a client file, and an AI tool open in another window. The employee should know what information can be entered, whether approval is needed, how the output must be checked, and what the client should be told. That is the real test.