The Architecture of Defensibility: Why AI Policies Are Not Enough

Disclosure: Artificial intelligence assisted with drafting and structural refinement. The author reviewed, revised, and checked the final content against the cited sources and accepts responsibility for the analysis and final form.

Disclaimer: I am an AI Integration Strategist, not a lawyer. This article addresses operational controls, technical risk management, and data governance. It is not legal advice. Canadian law firms should adapt the proposed controls to their circumstances. Vendor terms, features, and configurations change frequently; verify current documentation before relying on a provider's representations.

Professional guidance increasingly encourages firms to adopt generative AI policies — the Law Society of Alberta provides a model policy, and the Law Society of Ontario publishes policy-development resources.[3][4] A policy establishes authority, expected conduct, and responsibility. It cannot, by itself, configure accounts, restrict connectors, control information flows, or establish that required review actually occurred. That gap is closed by architecture: the contractual, technical, and procedural boundaries that embed governance decisions into accounts, permissions, configurations, and review processes.

Defensibility does not mean a control eliminates risk or guarantees compliance. It means the firm can explain what it approved, what conditions supported the approval, how those conditions were implemented, who was responsible, and what evidence shows whether they operated as intended. Consider two firms with identical AI subscriptions: one relies on policy and general reminders to verify; the other adds managed identities, assessed vendor terms, configured controls, review tied to consequence, and proportionate records. When a client inquiry, insurer review, or complaint arrives, the second firm can show how its policy was implemented. Architecture is evidence of an operating system — not proof that every decision within it was correct.

The Six Pillars

1. Identity, access, and administrative authority. Approval attaches to the actual service, tier, configuration, and use — not a vendor name in the abstract.[2][5][6] Administrative authority should be more restricted than user access: whoever can enable connectors or change retention settings can silently change the conditions supporting approval. Who can use the service, who can change the environment, and who can stop it?

2. Information boundaries. Classify what may cross which boundary for what purpose — public, internal, personal, confidential, privileged, and externally restricted information are different questions. The duty of confidentiality is broader than privilege, and privacy obligations apply independently.[1][8][9] Removing names may not anonymize: dates, transaction details, and unusual facts can still identify a matter. Consider information leaving through outputs, retained histories, shared links, and integrations as well as entering.

3. Contractual, vendor, and configuration controls. "We don't train on your data" addresses one risk among many. Assess six areas against the actual service and tier: information use, retention and deletion, access, subprocessors and location, security and incident obligations, and service-change rights. Enterprise protections may not apply to a consumer account, trial, or embedded feature. Contractual and technical controls must align — a restriction contradicted by the active configuration is incomplete, and a privacy setting creates no negotiated remedies.

4. Reliance, verification, and professional judgment. Review requirements follow intended reliance and consequence of error.[1][2][4][5][6][8] Before material reliance, verify authorities, quotations, procedural requirements, dates, and material facts against primary sources — then separately evaluate whether the propositions are current and applicable, and independently adopt the analysis. Forum-specific triggers matter: the Federal Court's notice (amended May 7, 2024) requires a declaration where submitted documents contain AI-generated content, but not where AI merely suggested changes a human considered and implemented.[7] Disclosure controls must reflect the forum's actual trigger, not a firm-wide assumption.

5. Evidence and records. Where AI materially informs advice, a filing, or another high-consequence decision, a proportionate Use and Verification Record should identify the service, permitted purpose, information category, verification performed, material corrections, and the responsible lawyer. It need not be a separate form — matter-management fields, metadata, and version history may already hold it. The objective is enough evidence to support the control purpose without creating a second, uncontrolled copy of the matter file.

6. Change, reassessment, and authority. Approval is not permanent. Material changes to features, terms, information categories, reliance, or users require a new decision — and the architecture must name who can suspend a service, grant an exception, accept residual risk, and authorize resumption. Architecture without defined authority can identify a problem without anyone empowered to act.

The Limits of Architecture

A control that obstructs legitimate work invites circumvention; improve the environment or narrow the use. And architecture can create false confidence: an approved environment can still be used for a task that should not be delegated, with information that should not be processed, or by a user without the competence to evaluate the output. Approval of a service never establishes task suitability or professional adequacy — those remain matters of supervision, verification, and judgment.

The Strategic Framework

Governance establishes authority and the conditions under which an AI use may proceed. Architecture translates those decisions into contractual, technical, and recordkeeping boundaries. Workflow design integrates the approved capability into legal-service delivery. Operational assurance tests whether approved use stays within its conditions. Governance defines the boundary. Architecture implements it. Assurance tests whether it holds.

Resources and References

[1] Federation of Law Societies of Canada, Model Code of Professional Conduct (Rule 3.1-2 and commentary on competence and technology; Rule 3.3-1 on confidential information). [2] Law Society of Alberta, The Generative AI Playbook, updated February 2026. [3] Law Society of Alberta, Why a Generative AI Use Policy? (includes the Model Generative AI Use Policy). [4] Law Society of Ontario, Using Technology (includes Generative AI: Your Professional Obligations and related checklists). [5] Canadian Bar Association, Ethics of Artificial Intelligence for the Legal Practitioner. [6] Law Society of Alberta, Gen AI Rules of Engagement for Canadian Lawyers. [7] Federal Court of Canada, Notice to the Parties and the Profession: The Use of Artificial Intelligence in Court Proceedings (PDF), amended May 7, 2024. [8] Law Society of British Columbia, Guidance on Professional Responsibility and Generative AI (PDF). [9] Office of the Privacy Commissioner of Canada and Canadian Privacy Regulators, Principles for Responsible, Trustworthy and Privacy-Protective Generative AI Technologies, December 7, 2023.