Most AI policies in professional-services firms fail in one of two directions. Some are a single paragraph that bans "sharing confidential information with AI tools" and tells nobody which tool, which information, or what to do instead. Others are a fifteen-page document drafted to impress a regulator that no working lawyer, analyst, or architect will read past the cover. Neither survives contact with a real deadline at 9 p.m., and neither protects the firm when something actually goes wrong.
A policy your compliance team will approve sits in between. It is specific enough that a senior associate knows, without asking, whether a given document can go into a given tool. It is short enough to be read. And it is structured so that if a client or the regulator ever asks how you handle their data, you can point to a written rule, show that your people were trained on it, and prove it was followed. That last part is the difference between a policy and a checkbox.
Start from data classification, not from tools
The most common mistake is to write the policy around tools: "ChatGPT is allowed, X is not." Tools change every quarter; your obligations do not. Anchor the policy in a small data classification scheme instead, three or four tiers at most, because a scheme with eleven categories is one nobody will apply correctly under pressure.
A workable scheme for a Mexican firm usually looks like this: Public (already published, marketing copy, public filings); Internal (drafts, templates, non-sensitive operational documents); Confidential (client work product, matter facts, financial statements, anything covered by secreto profesional or an NDA); and Restricted (personal data under the LFPDPPP, identity documents, health or financial records of identified individuals, anything whose leak triggers a notification duty). Every later rule keys off these tiers. Once a document is classified, the question "can I use AI on this?" has a defined answer rather than a judgment call made by whoever is tired and in a hurry.
Map allowed tools to tiers and to work
With tiers defined, the tool rules become a short table instead of a debate. Public and Internal data can flow to approved public models for drafting, summarizing, and research, provided outputs are reviewed by a person before they leave the firm. Confidential data may only be used in the firm's private or self-hosted configuration, where prompts are not used to train the model and data stays inside your control. Restricted personal data does not enter a general-purpose model at all, public or private, except under a specific, documented exception approved in advance.
Name the approved tools explicitly and keep that list in a place that can be updated without reissuing the whole policy, an annex, not the body. The policy should also state plainly what must never be pasted into a public model under any deadline pressure: client identities tied to matter facts, full financial statements before they are public, identity documents, credentials, and anything a client has asked you in writing to keep off third-party systems. Make this line short and absolute, because the exceptions are what get abused.
The components a defensible policy actually needs
A policy is defensible when each of these is written down, owned by a named role, and reflected in how your people were trained, not just published on the intranet.
- Data classification: three or four tiers with concrete examples from your firm's work, so anyone can place a document in seconds.
- Allowed tools by tier and task: which model is permitted for which class of data, and the human-review step required before any AI-assisted output leaves the firm.
- The hard line: an explicit, short list of what never enters a public model, with no implied exceptions.
- Retention and deletion: how long prompts, uploads, and outputs are kept in each tool, who deletes them, and confirmation that vendor settings disable training on your data.
- Incident path: what a person does the moment confidential or personal data goes somewhere it should not, who they tell, within what window, and who decides whether the LFPDPPP notification duty is triggered.
- Roles and responsibilities: a named policy owner, an approver for exceptions, and the obligation on every employee to verify AI output before relying on it.
- Legal alignment: explicit reference to the firm's LFPDPPP obligations and its sector confidentiality duties, so the policy reads as an extension of existing duties rather than a new IT rule.
Retention, deletion, and the incident path
Regulators and clients care less about whether you used AI and more about what happened to the data afterward. Your policy should state, per approved tool, how long inputs and outputs persist, whether the vendor retains them, and that data-retention and training settings have been configured to your standard, not left at the default. For confidential and restricted work, the answer should be that data is not retained by the vendor and not used to train the model, and you should be able to show the setting, not just assert it.
The incident path is the part most policies skip and the part a regulator will ask about first. Write it as a sequence a stressed person can follow: stop, preserve what happened, notify the named contact immediately, and do not attempt to quietly fix it alone. Define who assesses whether a breach of personal data triggers an LFPDPPP notification, and on what timeline, so the decision is made by the right person rather than by silence. A firm that can show a clear incident path and a trained team has a defensible story even when a mistake occurs; a firm relying on "our people are careful" does not.
Make it enforceable, then keep it alive
A policy nobody was trained on is not a policy; it is a liability you wrote yourself. Approval should depend on three things being true: every covered employee has been walked through the rules on their own real work, the approved-tools annex has a named owner who reviews it on a fixed cadence, and there is evidence, attendance, acknowledgments, configured settings, that the controls exist in practice and not only on paper. Build the policy this way and your compliance team is not signing off on aspirations. They are signing off on something they can defend to the client, the regulator, and a court, because it describes what the firm actually does.