# Sarhan Data Law — Full Content Library Generated: 2026-08-18T10:43:31.191Z Articles: 47 (21 blog posts, 16 static pages, 10 playbook chapters) --- ## Does SOC 2 Cover Your AI Model? URL: https://sarhandata.law/resources/soc-2-ai-model-gap Date: 2026-08-13 Category: Product Counsel You have a SOC 2 Type II report. It's current, it's clean, and your sales team sends it out with pride. Then an enterprise security reviewer asks: does your model memorize training data? How do you test for prompt injection? What happens to output quality when you swap model versions? And you realize the report answers none of it — because SOC 2 was never designed to. The Trust Services Criteria predate the current wave of AI products, and no amount of audit polish changes what the framework measures. This isn't an argument against SOC 2 — you still need it. It's a map of the specific gap between what your SOC 2 covers and what AI-era procurement now asks, plus the frameworks that actually close it. What SOC 2 Actually Covers SOC 2 is an attestation (technically not a "certification") by a CPA firm against the AICPA's Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. A Type II report tests whether your controls operated effectively over an observation period — typically 6–12 months. It answers: are your systems hardened, is access controlled, is data encrypted, are incidents handled, is uptime managed. For a conventional SaaS product, that's the question enterprise security teams need answered. For an AI product, it's roughly half the question. The Five AI Gaps Your SOC 2 Doesn't Touch 1. Model behaviour. The TSC has no criteria for what your model does — whether outputs are accurate, whether the model can be manipulated into harmful behaviour, whether it reproduces memorized training data. Your SOC 2 can attest that the model's infrastructure is secure while saying nothing about the model itself. 2. Training data provenance and governance. Where training data came from, whether you have rights to it, how it's documented, how it's segregated from customer data — none of that maps to a Trust Services Criterion. (It's now a diligence category of its own; see the chain-of-title piece.) 3. Model lifecycle and version management. Which model version serves production traffic, how updates are tested and rolled out, whether customers are notified before material changes, how you detect and respond to model drift. The TSC's change-management criteria address system changes; they don't capture "the model's behaviour shifted after a version upgrade" as a control objective. 4. AI-specific attack surfaces. Prompt injection, jailbreaks, data exfiltration through model outputs, cross-tenant context leakage in shared-model architectures. These are security risks, but they're not enumerated anywhere in the standard TSC control activities, so an auditor working from the standard framework has no obligation to test them. 5. Bias, transparency, and accountability. Whether outputs are tested for bias, whether limitations are documented, whether a human reviews consequential outputs, whether someone is accountable for the model's behaviour. Entirely outside SOC 2's scope. To be fair to the framework: you can incorporate AI controls into a SOC 2 examination — some TSC categories accommodate them, and sophisticated auditors will work with you to extend scope. But a buyer reading a standard SOC 2 report has no way to know whether that happened, which is why procurement teams have stopped assuming. What Enterprise Buyers Are Layering on Instead The procurement response to the gap shows up in three forms: AI-specific questionnaire sections. Distinct from the SOC 2 request: model governance, training data handling, output review, incident response for model failures, human oversight. These arrive whether or not your SOC 2 is clean. Contract clauses. AI-specific provisions — training prohibitions, model-update notification, retention configuration — that exist precisely because buyers learned SOC 2 doesn't cover them. A second framework: ISO/IEC 42001. Published in December 2023, ISO 42001 is the first certifiable international management-system standard for AI. Where SOC 2 asks "are your systems secure," ISO 42001 asks "do you manage AI as a governed lifecycle" — AI risk assessments, impact assessments, documented accountability, transparency requirements, bias mitigation, lifecycle controls from development through deployment and monitoring. It's structured like other ISO management standards (so an ISO 27001 shop reuses much of its machinery), and certification runs 6–18 months depending on your starting maturity. SOC 2 vs. ISO 42001: The Honest Comparison Dimension SOC 2 (Type II) ISO/IEC 42001 What it is Attestation by a CPA firm against AICPA Trust Services Criteria Certification against an international AI management-system standard Scope Security, availability, processing integrity, confidentiality, privacy AI risk, lifecycle governance, transparency, accountability, bias, human oversight Audience North American enterprise procurement Global; regulated industries; AI-specific diligence AI-specific? No — AI controls can be added but aren't required Yes, entirely Typical effort 3–6 months observation + audit 6–18 months to certification Replaces the other? No No — they stack; many organizations carry both One caveat worth stating plainly: ISO 42001 certification doesn't automatically make you compliant with the EU AI Act or any other regulation. It's a management-system credential, not a legal safe harbour. Its procurement value is that it gives buyers' AI-governance questions a documentable answer. The Practical Answer for an AI-Native Company * Keep SOC 2 current. It remains the price of admission for North American enterprise deals; its absence is a bigger red flag than its gaps. * Extend your SOC 2 scope deliberately. Work with your auditor to fold AI-relevant controls (model change management, AI incident response, training data segregation) into the examination so the report actually says something about them. * Build the AI governance artifacts regardless of certification. A model card, a model-version change log, a prompt-injection test summary, a training-data provenance statement, an output-review policy. These answer questionnaire sections today, without waiting for a certification cycle. * Treat ISO 42001 as a roadmap, not a gate. For most growth-stage companies, the management-system discipline (risk assessments, documented accountability, lifecycle controls) is worth adopting now; formal certification makes sense when a buyer segment starts requiring it — and in regulated industries, that moment is arriving. FAQ Does SOC 2 cover AI models and model behaviour? No. SOC 2's Trust Services Criteria cover security, availability, processing integrity, confidentiality, and privacy of your systems — not what your AI model does. Training data provenance, model versioning and drift, prompt injection, output quality, memorization, and bias are all outside the standard scope, though auditors can incorporate AI controls into an examination if you extend scope deliberately. What is ISO/IEC 42001 and how does it differ from SOC 2? ISO/IEC 42001 (published December 2023) is the first certifiable international management-system standard for AI — covering AI risk assessment, lifecycle governance, transparency, accountability, bias mitigation, and human oversight. SOC 2 is a US attestation about system security; ISO 42001 is a global certification about AI governance. They complement rather than replace each other, and many organizations carry both. Is SOC 2 still required to sell to enterprises? For North American enterprise procurement, effectively yes — it remains the baseline security credential, and its absence is a red flag. But buyers increasingly layer AI-specific questionnaires, contractual AI clauses, and (in regulated industries) ISO 42001 expectations on top of it. Does ISO 42001 certification mean we're EU AI Act compliant? No. ISO 42001 is a management-system credential, not a regulatory safe harbour. It can help structure and evidence the governance work the EU AI Act and similar regulations expect, but certification alone doesn't guarantee compliance with any specific law. --- ## Acquiring an AI Company? The Training-Data Diligence That Determines What You Actually Own URL: https://sarhandata.law/resources/acquiring-ai-company-training-data-diligence Date: 2026-08-05 Category: Business Transactions The standard technology diligence playbook was built for a different asset. IP assignment agreements, invention-assignment confirmations, data privacy policy review, cybersecurity posture — that checklist assumes the target's core asset is code, and that code's provenance is settled by employment contracts and clean-room development. When the target is an AI company, none of those assumptions hold. What you're actually buying is some combination of trained models, proprietary datasets, fine-tuning pipelines, and contractual rights to third-party models and data — most of which is undocumented, and some of which may not be the target's to sell. Deal counsel reading this: this is the diligence layer your technology specialists and IP counsel don't cover, because it sits at the intersection of privacy law, copyright, and contract — and it is where AI deal risk actually lives. The workstreams below are the difference between discovering problems in diligence and discovering them in a post-closing indemnity fight. 1. Training Data Provenance The threshold question: what data trained the models, and does the target have rights to it that survive the transaction? You're asking for documentation of how each training corpus was obtained — licensed (check field-of-use and sublicensing), scraped (check robots.txt/opt-out compliance and the jurisdiction's text-and-data-mining posture), customer-derived (check consent and DPA terms), or synthetic (check the upstream model's provenance — synthetic data inherits chain-of-title problems one level removed). Major firm guidance now treats training-data rights as fundamental representations in the purchase agreement — the kind that survive longer and carry larger caps — precisely because they can't be verified from the target's own assurances. The litigation backdrop matters: Thomson Reuters v. Ross Intelligence, Bartz v. Anthropic (US$1.5B settlement on the pirated-copies claim), and pending Canadian cases (a BC proposed class action against MosaicML/Databricks, and Canadian news media v. OpenAI in Ontario) mean the acquirer isn't just buying a model — it's buying a position in an unsettled legal landscape. (For the full review framework, see the chain-of-title piece.) 2. The Proprietary-vs-Dependency Map How much of the "AI" is actually the target's? Acquirers increasingly find the intelligence layer is a thin wrapper over a foundation model API, with the differentiation living in prompts and workflows that are neither owned nor defensible. Map it: proprietary models and weights (owned how, trained on what), fine-tunes of third-party models (does the provider's agreement give the target rights in the fine-tuned artifact, and are those rights assignable?), and pure API dependencies (what happens to unit economics and capability if the provider reprices, deprecates, or cuts off?). A target whose core capability depends on another company's model on non-assignable enterprise terms has a different valuation than its revenue multiple suggests. 3. Customer Data Consent Travel The target's customer contracts and privacy policy promised something about how customer data would be used — does that promise survive your ownership? In Canada, PIPEDA's business-transaction exception (s. 7.2) permits transfer without consent for the transaction, but post-closing use is limited to the purposes for which the information was originally collected (see the companion piece on PIPEDA diligence in acquisitions). If your thesis involves using the target's customer data in new ways — training your models, cross-selling into your portfolio, feeding your analytics — that's a new purpose requiring its own consent basis, and the acquisition price should reflect the gap. Quebec-based targets add s. 18.4 of Quebec's Private Sector Act (the commercial-transaction exception) with its own agreement requirements. 4. Contract Portability Two directions, both commonly missed. Vendor-side: the target's AI vendor agreements (model APIs, data licenses, cloud) — do they have change-of-control or assignment clauses that let a provider terminate or renegotiate on closing? A data license that terminates on change of control is a deal-critical finding. Customer-side: the target's customer MSAs and DPAs — same question in reverse, plus whether enterprise customers have consent rights on assignment that could trigger churn or renegotiation leverage at the worst moment. 5. Regulatory and Litigation Exposure Beyond the copyright landscape: does the target's product fall in scope of the EU AI Act's high-risk categories (obligations for which began applying August 2, 2026 under the current baseline, with a pending Digital Omnibus package that may adjust dates — verify against the Official Journal)? Any regulator correspondence, complaints, or inquiries (OPC, provincial commissioners, the CAI in Quebec, the FTC)? Any pending or threatened claims over outputs, training data, or customer data use? Any open-source license contamination in the model pipeline? And the governance question buyers now ask as a valuation input: does the target have an actual AI governance program — documented accountability, human-review workflows, incident history — or a policy PDF with nothing behind it? How the Findings Hit the Deal Diligence findings translate into deal mechanics, not just memos: * Reps and warranties: training-data rights, license compliance, and model performance as fundamental reps — sized to the risk uncovered, not boilerplate. * Indemnity structure: specific indemnities for provenance gaps that can't be fully resolved pre-closing, with caps and escrows matched to the actual exposure (a scraped-corpus problem prices differently than a consent-travel problem). * Price and structure: earnouts or holdbacks where value depends on unverifiable data rights; walk-away discipline where the core asset can't be warranted at all. * Post-closing covenants: consent remediation campaigns, contract re-papering, subprocessor re-papering — priced and scheduled before signing, not discovered after. For Sellers' Counsel (and Founders Reading This Backwards) Every finding above is cheaper to fix before the data room opens than during exclusivity. The seller-side version of this piece — what to build into your data room — is The AI M&A Data Room. The short version: a target that can produce a training-data provenance schedule, a dependency map, and a consent-quality audit on day one of diligence closes faster and at a better number than one that assembles them under deadline pressure. Last updated: August 2026. This article is educational and does not constitute legal advice. Transaction-specific diligence should be scoped with counsel; the litigation and regulatory landscape described here is moving quickly. FAQ What should due diligence on an AI company cover that standard tech diligence doesn't? Five things: training data provenance (does the target have rights that survive the transaction), a proprietary-vs-dependency map (how much of the "AI" is actually owned vs. rented from a model provider), customer data consent travel (whether post-closing uses exceed original collection purposes), contract portability (change-of-control and assignment clauses in AI vendor and customer agreements), and regulatory/litigation exposure (EU AI Act scope, pending copyright claims, regulator correspondence, governance posture). Can the buyer rely on the seller's representations about training data rights? Representations allocate risk; they don't verify it. Major firm guidance treats training-data rights as fundamental reps precisely because they can't be confirmed from the target's assurances — the underlying facts (how corpora were obtained, what licenses say, whether opt-outs were honoured) require document-level review. A rep without diligence behind it is a bet on the indemnity, and indemnities are only as good as the seller's ability to pay them. Does PIPEDA allow customer data to transfer with an acquired business? Yes, under the s. 7.2 business-transaction exception — with conditions (a written agreement, safeguards, necessity, and post-closing notification to individuals). But post-closing use is limited to the purposes for which the information was originally collected. Using the acquired database for new purposes (training the buyer's models, cross-selling) requires its own consent basis. Quebec adds s. 18.4 of the Private Sector Act with its own conditions. What happens to a target's AI vendor agreements on acquisition? Whatever the change-of-control and assignment clauses say — which is why they're a diligence item. Model API agreements, data licenses, and cloud contracts may terminate, require consent, or trigger renegotiation on a change of control. A data license that dies at closing can be a deal-critical finding; discover it in diligence, not integration. --- ## Business Acquisitions and PIPEDA: The Data Diligence That Deals Miss URL: https://sarhandata.law/resources/acquisitions-pipeda-diligence Date: 2026-08-05 Category: Business Transactions When a private equity firm acquires an e-commerce business, the value often lies in the customer database. Repeat purchasers, email subscribers, purchase history, marketing preferences — these assets drive the multiple. Yet in most Canadian M&A transactions, privacy diligence remains superficial. The deal team confirms a privacy policy exists, checks for obvious litigation, and moves on. The assumption is that customer data transfers seamlessly with the business. That assumption can be expensive. The Statutory Framework: What s. 7.2 Actually Says PIPEDA's business-transaction exception — s. 7.2, added by the Digital Privacy Act in 2015 — permits use and disclosure of personal information without the knowledge or consent of the individual in connection with business transactions (defined broadly: asset sales, mergers, corporate financing, securitization, leases and licences of assets). But it is a conditional exception, and the conditions differ between the prospective and completed phases. Prospective transaction (s. 7.2(1)) — due diligence and negotiation phase. Parties may use and disclose personal information without consent only if: * (a) the organizations have entered into an agreement requiring the receiving organization: * (i) to use and disclose the information solely for purposes related to the transaction, * (ii) to protect it by security safeguards appropriate to the sensitivity of the information, and * (iii) if the transaction does not proceed, to return or destroy it within a reasonable time; and * (b) the information is necessary both to determine whether to proceed and, if proceeding, to complete the transaction. Completed transaction (s. 7.2(2)) — post-closing. The exception continues only if: * (a) the parties' agreement requires the receiving organization: * (i) to use and disclose the information only for the purposes for which it was collected (the purpose-limitation condition), * (ii) to protect it with appropriate safeguards, and * (iii) to give effect to any withdrawal of consent made under clause 4.3.8 of Schedule 1; * (b) the information is necessary for carrying on the business or activity that was the object of the transaction; and * (c) one of the parties notifies the individual, within a reasonable time after completion, that the transaction completed and their information was disclosed. Two further provisions with teeth: s. 7.2(3) makes those agreements binding — an organization must comply with the terms of any agreement it enters under the exception (a breach is a PIPEDA contravention, not just a contract claim). And s. 7.2(4) carves out transactions whose primary purpose or result is the purchase, sale, or lease of personal information itself — a straight data-broker deal gets no exception at all. The provincial equivalents matter in cross-border deals: Alberta's PIPA (s. 22) and BC's PIPA (s. 20) have parallel business-transaction provisions with similar structure, and Quebec's Private Sector Act (as modernized by Law 25) has its own commercial-transaction exception at s. 18.4 — likewise conditioned on an agreement, use limited to concluding the transaction, and destruction if the deal dies. Quebec's definition of "commercial transaction" is broad, extending to financing and security creation. Where Acquirers Get It Wrong 1. The Purpose Limitation Trap The completed-transaction condition in s. 7.2(2)(a)(i) is where deals quietly break. The acquirer may use transferred personal information for the purposes for which it was originally collected — nothing more. Consider an e-commerce acquisition where the target collected customer data for order fulfillment, customer service, and marketing communications (with consent). The acquirer wants to cross-sell products from other portfolio companies, integrate the database with its existing CRM, and apply proprietary analytics to identify high-value segments. Each of those is plausibly a new purpose — beyond what a reasonable person would have understood at collection. PIPEDA then requires either that the new use fall within reasonable expectations or that fresh consent be obtained. "We own the database now" is not a legal basis. 2. Consent Quality Issues During diligence, ask: what exactly did customers consent to? Common findings: * Vague privacy policies that don't specify marketing uses, leaving consent scope ambiguous * Pre-checked boxes or bundled consents that don't meet the "meaningful consent" standard (s. 6.1 and the OPC's guidelines — consent is only valid if a reasonable person would understand the nature, purpose, and consequences) * No records of consent for legacy customers acquired before the target implemented proper consent management * Consent to the target, not to unnamed future acquirers — raising questions about whether consent "travels" with the transaction at all The OPC has been increasingly focused on consent validity — the Federal Court of Appeal's 2024 Facebook decision confirmed that "meaningful" consent is read seriously. An acquirer inheriting a database built on questionable consent inherits that liability. 3. Marketing Database Contamination (and CASL) E-commerce businesses often maintain multiple data categories: transactional customers, marketing-only contacts, and scraped or purchased third-party lists. The regulatory status of each differs — and CASL (Canada's anti-spam legislation) intersects significantly: commercial electronic messages run on express consent or implied consent through existing business relationships, with time-limited windows. Whether the target's implied-consent relationships and express consents support the acquirer's email program post-closing is a diligence question in its own right — don't assume consent and relationship transfer automatically with the asset sale. Acquirers who treat the entire database as a unified asset often discover, post-closing, that significant portions can't be marketed to lawfully. Diligence That Actually Protects Value Data mapping. Before assigning value to a customer database, understand what it contains: record counts and data elements, collection source per category, what consents exist and how they were obtained, opt-out/unsubscribe history, and records from jurisdictions with different rules (Quebec, EU). Privacy policy archaeology. The current privacy policy isn't sufficient — you need the policies in effect when data was collected: historical versions, changes in consent mechanisms over time, and any modifications made in response to complaints or regulatory guidance. Consent audit. For marketing databases: sample consent records to verify what customers agreed to; review language for specificity about marketing, third-party sharing, and transfer; identify reliance on implied consent that may not withstand scrutiny; assess Quebec-specific issues (Law 25's consent standard is stricter, and its commercial-transaction exception at s. 18.4 has its own conditions). Regulatory history. Any OPC or provincial commissioner complaints, prior inquiries or investigations, CASL compliance history, breach records (PIPEDA requires 24-month breach record-keeping — ask to see the register). Post-Acquisition Integration Notification isn't consent. Section 7.2(2)(c) requires notifying individuals within a reasonable time after closing — but notification alone doesn't authorize new uses. Practical approaches: * Segmented communication: inform customers of the acquisition and simultaneously request consent for new uses — but make the request distinct and genuinely optional * Sunset legacy data: for records with unclear provenance, run a re-engagement campaign that effectively refreshes consent * Ring-fence the database: if cross-selling isn't covered by existing consents, treat the acquired data as separated until proper consent exists * Honour withdrawals: s. 7.2(2)(a)(iii) requires giving effect to consent withdrawals under Schedule 1, clause 4.3.8 — your suppression lists need to survive integration CRM integration risk. Merging customer databases across portfolio companies creates purpose-creep risk. Owning multiple customer relationships doesn't mean they can be combined without attention to the consent basis for each. What This Means for Deal Teams For buyers: build privacy diligence into the standard playbook — not as a compliance checkbox but as a value assessment. A customer database is only worth what you can lawfully do with it. If post-acquisition plans require consent you don't have, the database is worth less than the model assumes, and the reps/indemnities should price that. For sellers: clean up data practices before going to market. Consent gaps, retention failures, and sloppy data management become diligence findings that erode valuation or become purchase-price adjustments. For M&A counsel: privacy has moved from "check the box" to material deal issue. Reps and warranties should be specific about consent quality, regulatory history, and data provenance. Indemnities should cover privacy claims arising from pre-closing practices. Post-closing covenants should address integration constraints. And where the target's value includes AI models or training data, the diligence extends further — see the companion piece on acquiring an AI company. The acquirer that inherits a privacy mess owns that mess. The Larger Point Customer data has become central to how businesses are valued. But data value depends on data usability, and usability depends on the legal foundations for how that data was collected and can be used. PIPEDA's s. 7.2 isn't an obstacle to transactions — it's a framework with specific, citable conditions: agreements in place (7.2(1)(a), 7.2(2)(a)), necessity tests (7.2(1)(b), 7.2(2)(b)), notification (7.2(2)(c)), binding effect (7.2(3)), and a carve-out for data-as-asset deals (7.2(4)). The deals that struggle are the ones that ignored those conditions until closing, then discovered the constraints too late to address them cleanly. FAQ Does PIPEDA allow customer data to be shared with a prospective acquirer during due diligence? Yes, under s. 7.2(1), without individual consent — but only if the parties have a written agreement requiring the recipient to use the information solely for purposes related to the transaction, protect it with safeguards appropriate to its sensitivity, and return or destroy it if the deal doesn't proceed; and only information necessary to decide whether to proceed and to complete the transaction may be shared. Can an acquirer use an acquired customer database for new purposes after closing? Not under the s. 7.2 exception alone. Section 7.2(2)(a)(i) limits post-closing use to the purposes for which the information was originally collected. New uses — cross-selling to other portfolio customers, novel analytics, AI training — require either that the use fall within what a reasonable person would have expected at collection, or fresh consent. The post-closing notification under s. 7.2(2)(c) is a notice obligation, not a consent substitute. Does the business-transaction exception apply when the deal is primarily about buying data? No. Section 7.2(4) excludes transactions whose primary purpose or result is the purchase, sale, other acquisition or disposition, or lease of personal information itself. A transaction that is fundamentally a data sale gets no consent exception. Do Quebec, Alberta, and BC have their own versions of the exception? Yes. Alberta's PIPA (s. 22) and BC's PIPA (s. 20) contain parallel business-transaction provisions, and Quebec's Private Sector Act (as modernized by Law 25) has a commercial-transaction exception at s. 18.4 — similarly conditioned on an agreement, use limited to concluding the transaction, and destruction if it doesn't proceed. Cross-border deals should map all applicable regimes, not just PIPEDA. --- ## The AI M&A Data Room: What Acquirers Will Ask For URL: https://sarhandata.law/resources/ai-ma-data-room-readiness Date: 2026-08-05 Category: Business Transactions Every founder prepping for an exit knows the standard data room: corporate records, financials, tax, contracts, customers, HR, IP assignments, security. What surprises AI-native companies is the second layer that now arrives with the first diligence request — questions about training data, model dependencies, and AI governance that weren't in anyone's checklist three years ago. M&A advisors now flag the same gap from the buy side: the most commonly missing documents in technology deals include IP assignment agreements and contracts with change-of-control provisions, and for AI targets the missing list gets longer — provenance records, licensing agreements, model documentation, and dependency maps. The companies that close fastest are the ones that built this layer before the process started. Here's what acquirers will ask for, why each item exists, and what to prepare. The Baseline Layer (Still Non-Negotiable) The standard ten categories still gate everything: corporate and governance, financial, tax, legal and contracts, customers and revenue, HR and employment, IP and technology, security and privacy, operations, regulatory. Two of the most commonly missing items deserve emphasis for AI companies because they intersect with the AI layer: IP assignment agreements for every founder, employee, and contractor (if a contractor wrote any of your model pipeline or data tooling without a clean assignment, that's a defect in the thing being acquired) and contracts with change-of-control provisions (your model API agreements, data licenses, and enterprise customer contracts — acquirers will map which ones survive your acquisition; see the buy-side piece). The AI Layer: Seven Document Sets 1. Training-data provenance schedule. A written inventory of what trained your models: each corpus's source (licensed, scraped, customer-derived, synthetic), the rights basis for each (license terms, opt-out compliance, consent basis), and any known gaps. Acquirers' counsel now treats training-data rights as fundamental representations — the schedule is what lets them be made honestly. If the honest answer includes "we're not sure about this segment," disclose it with the remediation plan rather than letting the buyer find it. 2. Data licensing or acquisition agreements. Every license or data acquisition agreement for training or fine-tuning data, with the field-of-use, sublicensing, and change-of-control provisions flagged. A data license that terminates on change of control is a valuation-relevant finding — surface it yourself. 3. Model dependency map. Which parts of your capability are proprietary (your weights, your fine-tunes, your pipelines) versus dependent (foundation model APIs, third-party embedding services). For each dependency: the agreement, the terms that matter (training use, retention, assignment), and your contingency if the provider reprices or deprecates. This map is what converts "we're an AI company" from a marketing claim into a diligence answer. 4. Model documentation and performance history. Model cards or equivalent: intended use, limitations, evaluation results, benchmark performance, and version history with a change log. If you've done bias or safety evaluations — internal or third-party — include the reports. Acquirers read a documented eval history as evidence the team operates like an engineering organization, not a demo. 5. Customer data terms inventory. Your DPA template and any negotiated variants, your privacy policy with version history (acquirers do "policy archaeology" — what did customers consent to when their data was collected), and your consent/withdrawal records. In Canada, the post-closing usability of your customer data runs through PIPEDA s. 7.2's purpose-limitation condition — the buyer is pricing what they can lawfully do with your database, and your consent records are the evidence (see the PIPEDA diligence piece). 6. AI governance artifacts. The operational evidence behind your governance posture: your written AI policy, the use-case register, human-review workflows for consequential outputs, your incident log (AI incidents, near-misses, how they were handled), and your subprocessor/vendor list with current data terms. Buyers have learned to distinguish a governance program from a policy PDF — the artifacts are the difference (see Do Enterprise Buyers Actually Care About Your AI Governance Policy?). 7. Regulatory correspondence and exposure register. Any regulator contact (OPC, provincial commissioners, the CAI in Quebec, FTC or EU authorities if applicable), any complaints or inquiries, any claims or demand letters involving your models, outputs, or data practices — plus your own assessment of where your product sits under the EU AI Act if you have European customers. "None" is a fine answer; "we'd have to check" is a diligence delay. The Preparation Timeline Sixty to ninety days before a process, in order: 1. Build the provenance schedule and dependency map — these take longest because they require archaeology, not drafting. 2. Paper the gaps you can paper — missing contractor IP assignments, unsigned DPAs, undocumented vendor terms. 3. Collect the artifacts that already exist — eval reports, change logs, incident records — into a single indexed folder. 4. Write the honest-gap memos — for anything that can't be fixed, a short memo stating the gap, the exposure, and the remediation plan. Buyers price known problems; they kill deals over discovered ones. 5. Run a mock diligence — have counsel or a trusted advisor play acquirer against the room for two days. The gaps you find are the ones the process won't. The Founder's Incentive This preparation reads like acquirer-pleasing homework. It isn't. It's exit-value protection: every undocumented data right, missing assignment, or surprise change-of-control clause converts into a price chip, an escrow, or a wider indemnity at the exact moment your leverage is lowest. And the same seven document sets answer the diligence questions in a priced round, the AI sections of enterprise procurement questionnaires, and the governance inquiries from your largest customers — build the room once and it works four ways. Last updated: August 2026. This article is educational and does not constitute legal advice. Transaction preparation should be scoped with counsel familiar with your specific cap table, contracts, and data practices. FAQ What do acquirers ask for in AI company due diligence? Beyond the standard data room (corporate, financial, contracts, HR, IP assignments, security), AI-era acquirers ask for: a training-data provenance schedule, data licensing agreements with change-of-control terms, a proprietary-vs-dependency map of the AI stack, model documentation and evaluation history, customer data terms with consent records, AI governance artifacts (policy, use-case register, incident log), and a regulatory correspondence register. What documents are most commonly missing in tech M&A data rooms? M&A advisors consistently flag: IP assignment agreements for founders and contractors, contracts with change-of-control provisions, and historical board consents. For AI targets the list grows: training-data provenance records, data licensing agreements, model documentation, and dependency maps — the items that determine what the acquirer actually owns. How early should an AI startup prepare its data room for acquisition? Sixty to ninety days before a process opens. Training-data provenance and dependency mapping require archaeology, not drafting — they're the longest-lead items. The same document set also serves priced-round diligence, enterprise procurement questionnaires, and large-customer governance reviews, so the preparation has multiple payoffs. Does a small AI startup really need documented AI governance for M&A? Yes — because buyers now distinguish governance programs from policy PDFs, and price accordingly. The artifacts that matter are operational: a use-case register, human-review workflows, an incident log, current vendor/data terms. They're also cheap to build at startup scale compared to retrofitting them under exclusivity pressure. --- ## Reviewing AI Model Training Data Rights: The Chain-of-Title Problem URL: https://sarhandata.law/resources/ai-training-data-rights-chain-of-title Date: 2026-07-30 Category: Data Protection & Cybersecurity Every AI model has a chain of title problem, whether or not anyone building or buying it has looked at it directly. The question is simple to ask and hard to answer: where did the training data actually come from, and does the model provider — or you, if you fine-tuned on your own data — actually have the rights needed to use it that way? This piece is about how to review that chain, not how to negotiate the contract clauses that follow from it (that's covered in the Enterprise AI MSA Playbook's IP and licensing chapter). This is the diligence question that comes before the negotiation. The Four Data Sources, and What Each One Actually Requires Training data behind any model generally falls into one of four buckets, and each carries a different set of questions. 1. Licensed corpora. Data the model provider (or you) obtained under an explicit license from a rights holder — a publisher, a data aggregator, a research consortium. * What to check: the license's field-of-use restrictions (does it permit AI training specifically, or only some narrower use?), whether the license permits sublicensing model outputs to third parties, and whether the license terminates or restricts use if the underlying agreement lapses. * The trap: a license negotiated before generative AI training was a foreseeable use often doesn't clearly cover it. A data license from 2015 that permits "internal research and analysis" is genuinely ambiguous about whether it covers training a commercial foundation model — and ambiguous licenses are exactly where disputes start. 2. Scraped or crawled web content. Data collected via automated crawling, without a direct license from each individual source. * What to check: whether the crawl respected robots.txt and any machine-readable opt-out signals, whether the source's terms of service prohibited automated collection (a contractual question, separate from copyright), and whether the jurisdiction where training occurred recognizes a text-and-data-mining exception that would cover the use even without a license. * The trap: this is the single most legally contested category right now, and the law is actively moving. In the EU, Article 4 of the Copyright in the Digital Single Market (DSM) Directive permits text-and-data-mining on lawfully accessible works unless the rights holder has reserved that right "in an appropriate manner" — and case law through 2025–2026 has been actively defining what "appropriate" means. A Danish court held in 2025 that a clear, accessible HTML policy statement (not necessarily a robots.txt entry) was sufficient to constitute a valid reservation; a German court addressing a similar question required a machine-readable signal specifically. This is not settled law, and a pending CJEU referral (Like Company v. Google Ireland, C-250/25) is expected to bear directly on how "appropriate reservation" gets defined going forward. Treat any current summary of this area, including this one, as provisional. * Canada specifically: unlike the EU, Canada's Copyright Act does not currently contain an explicit text-and-data-mining exception for AI training. Whether existing fair dealing provisions (Copyright Act, s. 29) extend to AI training use is unresolved — ISED's 2023-24 consultation on copyright and generative AI surfaced sharp disagreement between technology-sector stakeholders (who argue existing exceptions already permit TDM) and rights-holder groups (who argue expressive content used in training is not merely "data" and that a TDM exception would fail the Berne Convention's three-step test for permissible exceptions). No legislative resolution has been enacted as of this writing. 3. Customer or user data. Data your own customers provided to your product, now being considered for use in training or fine-tuning a model. * What to check: whether your terms of service or DPA with that customer actually permits this use — not just "improving the service," but specifically training or fine-tuning a model, ideally including whether outputs derived from it can be used with or sold to other customers. Under PIPEDA, if the data includes personal information, you need this to trace back to a valid basis under the "knowledge and consent" framework, and the OPC's guidelines on meaningful consent require that a reasonable person understand the nature, purpose, and consequences of the specific use — a generic "we may use your data to improve our services" clause is a real risk point if training use wasn't clearly within what a reasonable customer would have understood at the time of collection. Under GDPR, the equivalent question is which Article 6 legal basis applies (typically legitimate interest, requiring a documented balancing assessment, or consent). * The trap: consent or contractual language obtained for one purpose (service delivery) doesn't automatically extend to a materially different purpose (training a model that benefits other customers, or that could be sold or licensed separately). This is the single most common gap found in due diligence on companies training on their own customer data. 4. Synthetic data. Data generated by another model, rather than collected from any original human-authored source. * What to check: what training data produced the upstream model that generated your synthetic data, because synthetic data doesn't escape a chain-of-title problem — it inherits one, one level removed. If the upstream model was trained on improperly licensed data, synthetic outputs derived from it carry a version of the same exposure, even though no direct copy of the original work exists in your dataset. * The trap: treating "it's synthetic, so there's no IP issue" as a settled legal conclusion. It isn't settled, and overclaiming that synthetic data is legally clean without having actually traced the upstream provenance is exactly the kind of unverifiable claim that creates liability later. The Regulatory Overlay: What's Actually Required, Not Just Advisable * EU AI Act, Article 53 requires providers of general-purpose AI models to maintain a copyright-compliance policy and to make publicly available a "sufficiently detailed summary" of the content used for training. This is a live obligation for GPAI providers placing models on the EU market, regardless of where the provider is headquartered. * United States has no statutory text-and-data-mining exception and no federal AI training-data disclosure requirement. The sole defense for unauthorized use of copyrighted works in training is fair use under 17 U.S.C. § 107 — an open-ended, four-factor test (purpose and character of the use, nature of the copyrighted work, amount used, effect on the market) that applies to any purpose, not just a closed list. This is structurally different from Canada's fair dealing (limited to enumerated purposes in the Copyright Act) and from the EU's DSM Directive exception (which permits TDM subject to opt-out). The practical consequence: in the US, chain-of-title diligence for AI training is a fact-specific fair use risk assessment, not a compliance-box exercise — you're evaluating whether a court would likely find your specific use transformative and non-market-harming, not whether you satisfy a statutory exception. The US Copyright Office has issued guidance on AI output copyrightability (requiring human authorship for registration) but has not promulgated training-data-specific regulations. * Canada has no equivalent federal AI-specific training-data disclosure requirement currently in force. Bill C-27, which contained the proposed Artificial Intelligence and Data Act (AIDA), died on the order paper when Parliament was prorogued in January 2025; as of this writing, a replacement federal AI framework has been publicly signaled but not introduced. Provincial measures (Quebec's Law 25, Ontario's Bill 194) address AI use in narrower contexts but don't fill this specific gap. How This Is Evolving Through the Courts The legal framework for AI training data isn't being built by legislatures — it's being built by courts, case by case, on both sides of the border. The doctrinal gap that matters for diligence US fair use is open-ended: any purpose can qualify if the four-factor test is satisfied. Canada's fair dealing is a closed list: only research, private study, education, parody/satire, criticism/review, and news reporting qualify (Copyright Act, s. 29). While Canadian courts interpret these purposes "large and liberally," uses of copyrighted material for purposes outside the list are excluded from the exception entirely — and "training a commercial AI model" doesn't map cleanly onto any enumerated purpose. This means the same training activity that might survive a fair use defense in the US could fail a fair dealing analysis in Canada on threshold grounds alone, before the fairness factors are even weighed. The three US decisions that define the current landscape Case Court / Date Outcome What it turns on Thomson Reuters v. Ross Intelligence D. Del., Feb 11, 2025 Not fair use Ross used Westlaw headnotes to build a competing legal research tool. Direct market substitution; not transformative. First AI training fair use ruling on the merits. Not a generative AI case. Bartz v. Anthropic N.D. Cal., June 23, 2025 Fair use for training; not fair use for pirated copies Training on copyrighted books was "exceedingly transformative." But downloading pirated copies to build a "library" was not fair use — trial ordered on damages. Resulted in a US$1.5 billion settlement, believed to be the largest copyright settlement in history. Kadrey v. Meta N.D. Cal., June 25, 2025 Fair use, but explicitly narrow Training on copyrighted (and allegedly pirated) books was highly transformative. But the court stated the ruling "does not stand for the proposition that Meta's use of copyrighted materials to train its language models is lawful" — the plaintiffs failed to develop market-harm evidence. Different evidence could have changed the outcome. The emerging pattern across these three cases is not "training is always fair use" or "training is never fair use." It's market harm as the determining factor: when AI outputs compete with or substitute for the market the copyright owner controls (Thomson Reuters), courts find infringement; when they don't (Bartz, Kadrey), fair use survives — at least on the training itself. And there's a clear piracy bright line: using pirated source copies creates exposure that fair use may not cure, regardless of how transformative the training is (Bartz's pirated-copies ruling; Anthropic's $1.5B settlement). Both Bartz and Kadrey are on appeal, and the bellwether New York Times v. OpenAI case (S.D.N.Y.) — where the court denied OpenAI's motion to dismiss, finding the NYT plausibly alleged that ChatGPT outputs compete with NYT content — is expected to reach trial in late 2026 or early 2027. The final shape of US fair use for AI training will likely depend on these appellate and trial outcomes. The Canadian cases to watch Two Canadian lawsuits are testing the same questions, both still in early stages with no decisions as of this writing: * British Columbia proposed class action (MosaicML / Databricks, filed July 2025): alleges that MosaicML downloaded a dataset of pirated books to train its LLMs, and used software to remove copyright management information — a claim under the Copyright Act's anti-circumvention provisions as well as the core infringement claim. * Ontario lawsuit (Canadian news media companies v. OpenAI): alleges that OpenAI improperly scraped copyrighted content from the plaintiffs' websites, reproduced it into training datasets, circumvented technological protection measures, and breached the terms of use governing the plaintiffs' websites. What this means for your diligence review The practical implication is that chain-of-title diligence on AI training data cannot be a static checklist when the law is evolving case-by-case. Three things follow: 1. Document the market-relationship analysis. If your model's outputs could substitute for the works it was trained on (same industry, same audience, same use case), that's a materially higher risk profile than a model whose outputs serve a completely different purpose. This is the factor courts are actually weighing — your diligence should too. 2. Treat pirated sources as an absolute red line, regardless of how transformative the training might be. The Bartz court was willing to call training "exceedingly transformative" and still ruled against the pirated copies. If your provenance review finds pirated content in the training set, that's a finding that needs to be disclosed and remediated, not argued away. 3. Monitor the docket, not just the statute book. The law that will determine your exposure in 2026–2027 is being made in ongoing cases, not in legislation that hasn't been introduced. A diligence review completed today should be revisited when the next major ruling lands — particularly the NYT v. OpenAI trial and the Bartz/Kadrey appeals. The Contractual Artifacts That Actually Manage This Risk Diligence findings only matter if they translate into contract terms. Three specific artifacts do the work: * A training-data provenance schedule attached to any AI vendor agreement or M&A data-asset transfer — a specific, factual description of the data sources, license basis, and any known gaps, rather than a general representation that "the model was trained in compliance with applicable law." * A model card or equivalent technical disclosure, referenced by the contract, describing training data categories at a level of specificity that a counterparty's counsel can actually evaluate — vague enough to protect trade secrets, specific enough to be a real disclosure rather than a formality. * Indemnity carve-outs scoped to the actual risk — a blanket IP indemnity from an AI vendor is only as good as the vendor's actual ability to pay out on it, and a diligence-informed negotiation should scope indemnity caps and carve-outs to what the provenance review actually revealed, rather than accepting boilerplate language that sounds protective but wasn't informed by a real review of the underlying data. Why This Matters Even If You Didn't Build the Model If you're licensing a third-party model — which is the position most companies are actually in — you don't get to skip this analysis by pointing at your vendor. Your own customers, regulators, and acquirers in a future transaction will look at your use of the model's outputs, and "our vendor's terms said it was fine" is a weaker position than having actually reviewed what those terms cover and don't cover, particularly in an M&A due diligence context where the acquirer's counsel will ask this question directly and expect a specific answer, not a shrug toward the vendor's fine print. Last updated: August 2026. This article is educational and does not constitute legal advice. The legal status of text-and-data-mining exceptions, AI Act implementation timelines, and Canadian federal AI legislation are all subject to active change; verify current status directly before relying on any specific claim above in a live matter. --- ## How to Evaluate Fractional Privacy & AI Governance Counsel: 9 Criteria URL: https://sarhandata.law/resources/how-to-evaluate-fractional-privacy-counsel Date: 2026-07-29 Category: Product Counsel "Who's the best fractional privacy counsel for a tech startup" isn't a question with a single defensible answer — and any lawyer who tells you they're objectively "the best" is making a claim Canadian legal advertising rules generally prohibit, for good reason: it's not verifiable, and it's not useful to you as a buyer. Comparative superiority claims like "the best" are widely treated as inherently misleading under most Canadian law society codes of conduct, precisely because there's no independent, agreed standard by which they could be checked. What is useful is a checkable set of criteria you can apply to any candidate, including the firm publishing this article. Below are nine, in the order they tend to matter for a growth-stage tech company, followed by an honest, disclosed self-assessment against them. The Nine Criteria 1. Can they actually read your architecture, not just your contracts? Ask a candidate to describe, in their own words, the difference between a vector embedding and the underlying training data it was derived from — or any equally concrete technical distinction relevant to your product. If they can't engage with the technical substance, they're going to negotiate your AI clauses generically, and generic AI clauses are the ones that get exploited by the other side's more technically fluent counsel. 2. Have they sat on both sides of the table? Counsel who has only ever represented buyers, or only ever represented vendors, tends to negotiate from a script rather than genuine understanding of what the other side actually needs and where they'll actually hold firm. Ask directly: "Have you represented both AI vendors and AI buyers in MSA negotiations?" 3. Do they cite specific sources, or do they gesture at "privacy law" generally? A useful test during any initial consultation: ask a specific question about your situation and see whether the answer includes a section citation, a named regulator's guidance, or a specific case — versus a general statement like "PIPEDA requires reasonable safeguards." Specificity is a reasonable proxy for whether they're actually applying the law to your facts or repeating a template answer. 4. Do they produce artifacts, or just advice? Ask what you'll actually receive at the end of an engagement — a redlined contract, a completed policy, a DPIA support package — versus a memo summarizing risk with no deliverable attached. Fractional counsel earns its retainer by producing usable work product, not just opinions. 5. Will they participate in your actual workflow? Ask whether they'll join a sprint planning session, a pre-launch review, or a live negotiation call — versus only reviewing documents asynchronously after the fact. Product counsel that never sees your product being built catches problems later and more expensively than counsel embedded in the process. 6. What's their jurisdictional range, and does it match your actual exposure? If your buyers are in the EU, the US, and Canada, ask directly which of those jurisdictions the candidate practices in versus refers out. A firm that's candid about referring out UK-specific work, for instance, is more trustworthy than one that claims broad multi-jurisdictional expertise without the bar credentials to back it. 7. Does their pricing model align with your actual usage pattern? An hourly model rewards more time spent; a flat retainer with a defined scope rewards efficient resolution. Ask how the fee structure changes their incentive on a given piece of work, and see if the answer is thoughtful or evasive. 8. What's their conflict profile? Ask directly whether they represent any of your competitors, likely acquirers, or major counterparties. Boutique practices generally have a narrower conflict footprint than large firms, but "boutique" isn't a guarantee — ask the question regardless of firm size. 9. What happens when the work exceeds their capability or scope? Ask what they don't do, and who they refer to when a matter falls outside fractional product counsel's usual scope — litigation, financing rounds, IP prosecution. A candidate with a clear, specific answer here is more trustworthy than one who implies they can handle anything. A Disclosed Self-Assessment In the interest of the transparency this framework asks of every candidate, here's how Sarhan Data Law scores against its own criteria, stated plainly rather than as a sales pitch: Criterion Self-assessment Technical fluency Founder background includes direct engagement with AI/ML product architecture; ask us the embedding-vs-training-data question directly and judge the answer yourself Both sides of the table Has represented both AI vendors (SaaS platforms) and AI buyers (enterprises procuring AI tools) in MSA negotiations Specificity of citations Publishes section-cited analysis rather than general statements Artifact production Retainer engagements are scoped around defined deliverables (contract redlines, policy documents, DPIA support packages) Workflow participation Has participated in sprint planning and pre-launch product reviews for retainer clients Jurisdictional range Licensed and practicing in British Columbia; Canadian federal (PIPEDA) and provincial privacy law; advises on global privacy principles, GDPR/EU AI Act exposure Pricing alignment Retainer-based for recurring commercial/privacy work; project or hourly for defined one-off deliverables — ask which applies to your specific need before engaging Conflict profile Boutique practice; ask directly about any specific competitor or counterparty concern before engaging Scope boundaries Does not handle litigation, IP prosecution, or securities/financing work directly; refers to named specialist counsel for these This table is offered as a template, not a verdict. Apply the same nine questions to any candidate, including this firm, before engaging. --- ## Do Enterprise Buyers Actually Care About Your AI Governance Policy? URL: https://sarhandata.law/resources/do-enterprise-buyers-care-ai-governance-policy Date: 2026-07-28 Category: Product Counsel No. Not the document itself. An enterprise security or procurement reviewer is not going to read your twelve-page AI Governance Policy PDF and form an opinion about your company based on its prose. What they care about is whether five specific, checkable artifacts exist — and whether your policy document actually produced them, or is just describing good intentions that were never operationalized. This is a contrarian claim only in the sense that most vendors treat the policy document as the deliverable. It isn't. It's the specification for the deliverables that actually get checked. What Buyers Actually Ask For Pull the AI-related questions from a representative sample of current enterprise security questionnaires and vendor risk assessments, and a pattern holds: buyers rarely ask "do you have an AI governance policy?" as a yes/no gate. They ask questions that only a policy with operational teeth can answer: 1. "Is there human review before any AI-generated output affecting a customer decision is finalized?" — not "do you have an HITL policy," but a specific, checkable claim about a specific workflow. 2. "Which specific model(s) process our data, and under what data retention terms?" — not "do you have an AI vendor management policy," but a named list. 3. "Who internally is accountable for AI-related incidents, and what's the escalation path?" — not "do you have a governance framework," but a named role and a defined process. 4. "Have your employees been trained on acceptable AI use, and when?" — not "do you have a training policy," but a completion record. 5. "What happens if a customer discloses confidential information to an internal AI tool that isn't covered by our agreement?" — not "do you prohibit shadow AI," but evidence of an actual technical or procedural control. None of these questions can be answered with a policy document alone. Each requires the policy to have produced an artifact: a workflow, a vendor list, a named accountable role, a training log, a control. The document is the specification. The five items above are the deliverables procurement teams are actually checking for. Why the Document-Only Approach Fails Specifically at the Deal Stage A governance policy that exists only as a document tends to fail in one of two predictable ways when it hits a real enterprise review: * It's too vague to answer the specific question asked, because it was written to sound comprehensive rather than to produce checkable commitments. "We are committed to responsible AI use" doesn't answer "who is accountable when something goes wrong," and a reviewer will notice the gap immediately. * It describes a process that was never actually built, and the first time a buyer asks for evidence — a training completion log, a named accountable role, a documented model list — there's nothing to produce. This is worse than not having a policy at all, because it now reads as a misrepresentation rather than an honest gap. What This Means for How You Should Actually Build the Policy If the document itself isn't the point, the build process should invert from how most companies approach it. Instead of starting with policy language and hoping operational reality catches up, start with the five checkable artifacts and write the policy to describe what's actually true: * Build the human-in-the-loop workflow first, then document it. Don't write an HITL commitment and hope engineering implements it later. * Maintain a live AI vendor/model inventory — which models, which data, what retention terms — as a standing artifact, not a one-time list buried in an appendix. * Name an actual accountable person or role, not "the AI governance committee" as an abstraction. A specific name or title that a security reviewer can ask a follow-up question about. * Actually run the training and keep the completion record. This is the single easiest artifact to fake and the easiest one for a diligent buyer to catch you faking, because it's usually the first thing they ask to see evidence of. * Build the shadow-AI control as an actual technical or procedural measure (blocked domains, an approved-tools list enforced somehow, a disclosure requirement in onboarding) — not a sentence in a policy that nobody enforces. The Uncomfortable Corollary If your policy document is comprehensive and well-written but none of these five artifacts exist behind it, you are worse off in an enterprise deal than a competitor with a rougher-looking, two-page policy that maps directly to a named accountable person, a real training log, and an actual model inventory. Sophistication of prose is not what's being scored. Operational specificity is. This also means the "do buyers care" question has a sharper answer than a simple yes or no: buyers don't care about the policy as an artifact of intent. They care about it as evidence of five specific operational facts. Build for the facts, and the policy document becomes almost incidental — a cover page for work you've actually done, rather than a substitute for work you haven't. --- ## Is Fractional Product Counsel Worth It Before Series B? URL: https://sarhandata.law/resources/fractional-product-counsel-before-series-b Date: 2026-07-27 Category: Product Counsel Short answer: the trigger isn't Series A or Series B. It's the first week you have three enterprise contracts in flight at once and no one in-house who can read them. For most B2B SaaS companies that happens somewhere between $1M and $4M ARR — which can be well before Series A or well after Series B, depending on your sales motion. Funding stage is a proxy. Contract volume is the actual variable. Below is the cost math three ways, the specific trigger to watch for instead of a funding round, and the cases where fractional counsel is the wrong purchase. The Three Real Options, Priced Honestly At the stage where this question comes up, a growth-stage tech company has three actual choices, not two: 1. Do nothing / founder handles it. Zero direct cost. The real cost shows up later, as delay and bad terms (see below). 2. Pay hourly, as-needed, at a traditional firm. Vancouver/Toronto tech-focused firms typically run $450–$850/hour for a senior associate or junior partner reviewing a commercial contract. A single enterprise MSA review, with one round of negotiation, commonly runs $3,000–$8,000 in fees — and that's per contract, with no continuity between deals. 3. Fractional counsel on retainer. A monthly retainer for embedded product/privacy counsel at a boutique tech-focused practice typically runs in the low-to-mid five figures annually, structured as a fixed monthly fee with defined scope (contract review up to a cap, standing office hours, template maintenance) plus a stated hourly or project rate for anything above scope. The comparison that matters isn't "retainer cost vs. $0." It's retainer cost vs. hourly cost at your actual contract volume, plus the cost of the mistakes that happen when nobody reviews contracts at all. The Trigger That Actually Matters Ignore the funding round. Watch for these three signals instead — any one of them means you've entered the window where fractional counsel usually pays for itself: * You have signed, or are about to sign, an enterprise customer with a security questionnaire, a DPA, and a redlined MSA — at the same time. This is the moment templates stop being optional. * Your sales team has started saying "let me check with legal" and there is no legal to check with. Every deal that stalls here costs more in lost velocity than a year of retainer fees. * You're negotiating your first AI-specific clauses — training data rights, output ownership, liability caps tied to model behaviour — where a generic SaaS MSA template doesn't fit and getting it wrong creates exposure that's expensive to unwind later. If none of these have happened yet, the honest answer is: wait. Buying fractional counsel before you have contract volume is optimizing for a problem you don't have yet, and boutique practices worth hiring will generally tell you this rather than sign you early. What the Retainer Actually Buys You The value isn't "someone to call when there's a problem." It's four things a traditional hourly relationship structurally can't offer: * Continuity. The same counsel who negotiated your last enterprise MSA remembers what you conceded last time and won't re-litigate it. * Template ownership. Your DPA, security exhibit, and MSA improve after every deal instead of being rebuilt from scratch each time. * Predictable spend. A monthly number your finance team can plan around, instead of a variable hourly bill that spikes exactly when you're closing your biggest deal of the quarter. * Product-embedded judgment. Counsel who has sat in your sprint planning or roadmap reviews catches privacy-by-design and contract-risk issues before they're shipped, not after a customer's security team finds them. When Fractional Counsel Is the Wrong Purchase This is the section most firms won't write, so it's worth being direct about it: * If you have fewer than two enterprise-track deals in your pipeline, you don't have enough contract volume to justify a retainer yet. Use hourly review per deal instead. * If your buyer is exclusively SMB/PLG self-serve with click-through terms, you likely don't need embedded counsel at all — a solid set of static templates, reviewed once, will carry you further than you'd expect. * If you're about to raise a priced round, that work (cap table, financing docs, investor negotiation) is a different skill set than product/privacy counsel, and a fractional product counsel arrangement won't cover it. You'll want separate counsel for the raise itself. * If you need litigation, IP prosecution, or securities work, none of that is what "fractional product counsel" describes. Don't buy a retainer expecting it to cover deal types it wasn't built for. The Actual Decision Rule Retainer math works out in your favour once your enterprise contract volume exceeds roughly one meaningful commercial negotiation per month. Below that, hourly is cheaper. Above that, hourly is a false economy — you're paying a premium per contract for the privilege of re-explaining your business to a new reviewer every time, and your sales cycle absorbs the delay. That's the actual trade-off. Not "can we afford it," but "does our deal volume make continuity worth more than the marginal cost of the retainer." For most companies, that's a Series A-adjacent question in timing only because that's when enterprise pipeline usually starts looking real — not because a funding round itself changes anything about your legal risk. --- ## Canada's CDBA Draft Regulations Are Here: What Fintechs Need to Prepare For URL: https://sarhandata.law/resources/cdba-draft-regulations-fintech-readiness Date: 2026-07-06 Category: Data Protection & Cybersecurity When the Consumer-Driven Banking Act (CDBA) received Royal Assent on March 26, 2026, it established the legal foundation for Canada's open banking framework. But a legal foundation without operational rules is a house without plumbing. The Act left the hard part — accreditation criteria, security standards, consent mechanics, liability allocation, record keeping, enforcement — to regulation. On June 27, 2026, the Department of Finance published the proposed Consumer-Driven Banking Regulations in Canada Gazette Part I (Volume 160, Number 26), launching a 60-day public consultation period that runs until August 26, 2026. For the first time, we can see how the framework will actually work. The Regulations are not final. They are subject to stakeholder feedback, and the Bank of Canada has indicated it will publish additional guidelines on accreditation, data usage, consent management, and data sharing. But the direction is clear enough that fintechs should be preparing now, not waiting for final publication. This post breaks down what the draft Regulations actually require, what they leave open, and what fintechs should be doing during the consultation window. Oversight: Who Runs the Framework The Bank of Canada is the primary supervisor. Under the CDBA and the draft Regulations, the Bank is responsible for: * Accrediting participating entities and maintaining a public registry * Supervising compliance with the Act, Regulations, and technical standards * Monitoring market and consumer trends * Enforcing the framework through suspension, revocation, compliance agreements, and administrative monetary penalties (AMPs) The Department of Finance led the development of the Regulations with support from the Bank. The Minister of Finance retains national security authorities — including the power to direct the Bank to refuse, suspend, or revoke an entity's participation, and to impose conditions or require undertakings from applicants, participating entities, or Accredited Third-Party Service Providers (ATPSPs). A Consumer-Driven Banking Advisory Committee provides industry perspective and advice to both the Bank of Canada and the Department of Finance. Accreditation: Four Pathways Any entity that wants to participate in consumer-driven data sharing — other than banks mandated to participate — must be accredited by the Bank of Canada. The draft Regulations establish four accreditation pathways tailored to entity type: Pathway Who It Covers Streamlined? Key Requirements 1. Fintechs and other entities Non-regulated businesses, technology firms No (full accreditation) Proof of Canadian presence, insurance coverage, baseline security controls, integrity and good character policy for key personnel, full information submission 2. RPAA-registered PSPs Payment service providers registered under the Retail Payment Activities Act Yes Leverages existing RPAA regulatory oversight; declaration of security compliance rather than starting from scratch 3. Federal/provincial FIs Banks, credit unions, other regulated financial institutions not mandated to participate Yes Leverages existing prudential/regulatory oversight 4. ATPSPs Accredited Third-Party Service Providers (aggregators, consent managers) Separate pathway Can perform specific activities (consent management, authentication, data movement) on behalf of participating entities; cannot operate on their own behalf All applicants must submit through the Bank of Canada's electronic system. The prescribed accreditation fee is C$2,500, subject to annual indexation. Participating entities will also be subject to ongoing annual assessment fees once the framework becomes operational. What this means for fintechs: If you're not already regulated under the RPAA or as a federal/provincial financial institution, you're in Pathway 1 — the most extensive accreditation process. The requirements include demonstrating a place of business in Canada, maintaining insurance coverage, implementing baseline security controls, and having an integrity and good character framework for key personnel. This is not a rubber stamp. ATPSPs are a distinct category. They are not participating entities. They can only operate on behalf of a participating entity, and the participating entity remains liable for the ATPSP's activities. This matters for fintechs that currently act as aggregators — you'll need to decide whether to seek full accreditation as a participating entity or operate as an ATPSP under a sponsor. The Small Fintech Access Problem The draft Regulations have drawn immediate industry feedback on a structural concern: the cost and complexity of full accreditation may be prohibitive for smaller fintechs. On June 8, 2026, the Financial Data and Technology Association (FDATA) submitted a formal proposal to the Department of Finance and Bank of Canada recommending a Sponsored Fintech Model (SFM). The proposal would allow accredited aggregators or data intermediaries to serve as sponsors for smaller fintechs, providing the API infrastructure, consent management, and compliance oversight that the CDBA requires. Sponsored fintechs would still be subject to national security screening, data minimization commitments, and independent audits — but without the full accreditation burden. The government's own Regulatory Impact Analysis Statement acknowledges the disproportionate impact on small businesses, noting that approximately 578 of the 680 affected businesses are small businesses and that many compliance costs are fixed, representing a larger burden relative to firm size. The consultation period is the window to weigh in on this. If you're a smaller fintech, the accreditation cost question is the one most likely to determine whether you can participate in Canada's open banking ecosystem at all. Security Requirements The draft Regulations prescribe detailed security safeguards that participating entities must implement and maintain. These are not principle-based aspirations — they are specific, operational requirements: * Asset inventory and vulnerability management programs * Configuration standards for systems and endpoints * Identity and access management controls * Encryption of data in transit and at rest * Backup and recovery procedures * Network monitoring and threat detection * Third-party contract review (including cloud and vendor risk management) * Cybersecurity training programs * Incident response testing and breach reporting templates with escalation paths to the Bank of Canada The Bank of Canada will develop and publish guidelines on these requirements ahead of the Act's coming into force. But fintechs should not wait for those guidelines. The requirements broadly align with established security frameworks (ISO 27001, NIST), and the work of building a security program that meets this standard is a months-long effort, not a weeks-long one. Consent and Authentication Consent is the engine of the consumer-driven banking framework. The draft Regulations specify: * Express consent is required before any data access — no implied consent, no opt-out models * Authentication steps must be implemented to verify consumer identity before data is shared * Consumer signs and notices must be displayed in the prescribed form * Consumers can revoke consent and request deletion of their data at any time * Consent records must be maintained with protections against loss, destruction, and falsification For fintechs, this has direct product implications. Your consent flows, data retention policies, terms of service, and user experience all need to be built around express consent and revocation. If a consumer revokes consent, you need to be able to demonstrate that you stopped accessing their data and handled any previously accessed data in accordance with the deletion request. This intersects with PIPEDA's data mobility provisions, which were also amended through Bill C-15. The compliance surface is broader than the CDBA alone — fintechs handling financial data accessed through the framework need a privacy compliance program that accounts for both regimes simultaneously, not two separate programs running in parallel. Record Keeping: Five-Year Retention Participating entities must retain records demonstrating compliance with the CDBA and its Regulations for five years. Records must be stored electronically in a format intelligible to the Bank of Canada and protected against loss, destruction, falsification, inaccuracies, and unauthorized access. This is consistent with the record retention requirements under the Retail Payment Activities Act, which means RPAA-registered PSPs may already have infrastructure that can be extended. For fintechs without existing record-keeping frameworks, this is a build requirement. The scope of what must be retained is broad: compliance records, consent records, data sharing logs, breach reports, security safeguard documentation, and complaint records. This is not just a data retention policy — it's an information governance framework. Annual Reporting Participating entities must submit an annual report to the Bank of Canada containing prescribed information, including: * Consumer data sharing activities * Express consents granted and deletion requests received * Changes to security safeguards, policies, and procedures * Security breaches * Financial performance metrics * Continued compliance with applicable technical standards The annual report is the Bank of Canada's primary supervisory tool. Fintechs should design their reporting infrastructure before they need it, not after the first reporting deadline. Breach Reporting Security breaches must be reported to the Bank of Canada "as soon as feasible." This mirrors the language in PIPEDA's breach reporting provisions (s. 10.1), which also require reporting "as soon as feasible" to the Privacy Commissioner of Canada when a breach poses a "real risk of significant harm." Neither regime prescribes a fixed deadline (unlike GDPR's 72-hour rule) — both rely on a reasonableness standard. The key difference for CDBA participants is that a breach within the framework may trigger reporting obligations to both the Bank of Canada and the OPC simultaneously, plus notification to affected consumers. This means your incident response playbook needs escalation paths to the Bank of Canada, not just to affected consumers and the Privacy Commissioner. A breach within the CDBA framework could trigger reporting obligations to multiple regulators simultaneously. National Security Review The Minister of Finance has national security authorities that overlay the entire framework. The Minister can: * Review applicants and accredited entities for national security risks * Direct the Bank of Canada to refuse, suspend, or revoke an entity's participation * Require undertakings from, or impose terms and conditions on, applicants, participating entities, or ATPSPs The draft Regulations specify the timelines and information requirements for the national security review process. Applicants must provide information including corporate ownership, governance structure, foreign regulatory status, and details about persons subject to integrity and good character assessments. For fintechs with foreign ownership or cross-border operations, this is a gatekeeper worth taking seriously. The national security review is not a formality — it's a substantive assessment that can block participation. Liability: The Framework Takes Shape The existing post on the CDBA noted that liability rules were among the most consequential and least resolved questions. The draft Regulations begin to fill this gap. The framework establishes liability-related consumer notices — participating entities must provide consumers with information about liability allocation in the prescribed form. The Regulations also prescribe complaint procedures that participating entities must implement and follow. The emerging principle — consistent with the government's policy documents — is that liability follows control. Once a bank transfers data to an accredited third party through a mandated API, the bank's exposure ends at the point of transfer. The receiving entity owns what happens next. But the chain complexity remains. What happens when a breach involves multiple parties — a bank, an ATPSP, and a fintech? What's the standard of care for a fintech holding consumer financial data? What happens when consent is revoked but data has already moved downstream? The Regulations provide the framework for these questions but do not answer all of them. The Bank of Canada's forthcoming guidelines are expected to provide additional clarity. Data Scope: What's Covered The Act specifies that participating entities will be required to share, at a consumer's request, both data provided by the consumer and product data related to: * Deposit accounts * Payment products * Investment accounts * Lending accounts The Regulations clarify that the data covered includes: * Identity of consumers associated with the products or services * Account numbers, branch numbers, transit numbers, and other identifiers * Current or past balances or amounts owing * Data pertaining to completed, pending, or pre-authorized transactions * Product terms and conditions under which products or services are available or offered This is the Phase 1 scope — read access. The government has confirmed that the screen scraping prohibition will not come into force as part of the initial implementation. Future policy work will consider a broader second phase, including "write access" functionality such as payment initiation, account opening, and account closure. Enforcement The draft Regulations designate violations for contraventions of a broad range of Act provisions and specified regulation provisions, including: * Accreditation requirements and suspension conditions * Data sharing obligations and service standards * Privacy, security, and breach reporting obligations * Authentication and consent requirements * Record keeping and annual reporting * Technical standards compliance * Non-compliance with compliance agreements or Bank directions Enforcement tools available to the Bank of Canada include suspension, revocation of accreditation, compliance agreements, and administrative monetary penalties. What's Still Open The draft Regulations represent significant progress, but several elements remain to be finalized: 1. Technical standards body — The Regulations reference a technical standards body responsible for establishing the single technical standard applicable to all participating entities, but it has not been designated 2. Bank of Canada guidelines — The Bank plans to issue guidance on accreditation, data usage, consent management, and data sharing 3. External complaints body — A body to provide consumer-driven banking dispute resolution services is referenced but not named 4. Screen scraping prohibition — Deferred from initial implementation; no timeline confirmed 5. Phase 2 / write access — Payment initiation, account opening, and account closure are future policy work, contingent on the Real-Time Rail 6. Final regulations — The current draft is subject to the 60-day consultation; final publication will follow Staggered Implementation The Regulations will come into force in a staggered approach, beginning with accreditation. Requirements related to common rules and assessment fees will follow within one year of final publication. Further details on the coming-into-force timing for different products and services will be set out when the final regulations are published. This means the accreditation window will open first — and the fintechs that are ready to apply on day one will have a structural advantage. The Consultation Window: August 26, 2026 The 60-day consultation period closes on August 26, 2026 at 11:59 p.m. EDT. Stakeholders can submit feedback through: * The Canada Gazette online commenting feature * Email to obbo@fin.gc.ca, citing Canada Gazette Part I, June 27, 2026 This is not a passive exercise. The draft Regulations address issues that will directly shape the competitive landscape — accreditation costs, liability allocation, the role of ATPSPs, the treatment of small fintechs. The entities that engage with the consultation process are the ones that will influence the final rules. What Fintechs Should Be Doing Now 1. Map your accreditation pathway. Determine which of the four pathways applies to your business model. If you're a non-regulated fintech, start preparing for Pathway 1 requirements now — Canadian presence, insurance, security controls, integrity framework. 2. Conduct a security gap assessment. Compare your current security program against the prescribed requirements. The gap between where most early-stage fintechs are and where the Regulations require them to be is wider than expected. 3. Design your consent architecture. Build for express consent, revocation, and deletion — not as features bolted on later, but as core product infrastructure. 4. Build your record-keeping framework. Five years of compliance, consent, data sharing, and breach records, in a format the Bank of Canada can inspect. This is an information governance build, not a policy document. 5. Engage with the consultation. Submit feedback on the issues that matter to your business — accreditation thresholds, the sponsored fintech model, liability allocation. The window closes August 26. 6. Integrate CDBA compliance with your privacy program. The CDBA doesn't operate in isolation. It sits alongside PIPEDA (including the new data mobility amendments), the RPAA, and provincial privacy legislation. Design one compliance architecture that accounts for all of them. The fintechs that win in Canada's open banking ecosystem won't just be compliant. They'll have built compliance into the product from the start — and they'll have shaped the rules during the consultation window rather than reacting to them after they're final. --- ## Navigating the PIPEDA-PHIPA Intersection: What Healthtech Companies Need to Know URL: https://sarhandata.law/resources/pipeda-phipa-healthtech-companies Date: 2026-06-30 Category: Healthcare The Canadian healthtech landscape presents a unique regulatory puzzle. You’ve signed the pilot, the clinical champion is on board, but now you’re stuck in a 12-month privacy review loop because both your operational champion and you are unsure exactly what laws and regulations apply and to whom. Canadian health data protection is layered across federal and provincial regimes and the interactions between them aren't always intuitive. For healthtech companies building products that touch patient data, understanding where PIPEDA ends and provincial health privacy laws begin directly affects your product architecture, your contracting, and your ability to sell into health systems without getting stuck in pilot purgatory. The Jurisdictional Framework PIPEDA (Personal Information Protection and Electronic Documents Act) is federal legislation that governs how private-sector organizations collect, use, and disclose personal information in the course of commercial activity. It applies across Canada, except in provinces that have enacted "substantially similar" legislation. Provincial health information statutes—including Ontario's PHIPA (Personal Health Information Protection Act) and Alberta's HIA (Health Information Act)—create sector-specific rules for "health information custodians" and those who handle personal health information on their behalf. British Columbia does not have an equivalent private-sector health privacy statute; private health organizations in BC operate under PIPA, which is substantially similar to PIPEDA. The critical question for any healthtech company: Which regime applies to us? When PHIPA Applies (Ontario Example) PHIPA applies when: 1. You are a "health information custodian" (HIC)—defined in Section 3(1) to include physicians, hospitals, pharmacies, long-term care homes, and certain other prescribed entities; or 2. You are processing personal health information on behalf of a HIC as an "agent" (defined in Section 2) or through a service agreement. If you're a SaaS vendor providing software to an Ontario hospital, you're likely caught by PHIPA through your relationship with the hospital, even if you're not a custodian yourself. The hospital's obligations flow through to you contractually, and PHIPA's requirements—including breach notification, access rights, and security safeguards—apply to your handling of that data. When PIPEDA Applies PIPEDA continues to apply to: 1. Direct-to-consumer healthtech that isn't operating through a custodian relationship (think: wellness apps, fitness trackers, mental health platforms with no clinical integration) 2. Commercial activities that fall outside the health custodian relationship, even for companies that also serve custodians 3. Interprovincial and international data flows, where PIPEDA often remains the governing framework regardless of provincial health laws Comparison: PIPEDA vs. PHIPA at a Glance Feature PIPEDA (Federal) PHIPA (Ontario) Primary Scope Commercial activities Health Information Custodians (HICs) Consent Model Meaningful consent (explicit for sensitive data) Implied consent assumed within "Circle of Care" (s. 20(2)) — IPC-interpreted concept, not a statutory term Breach Reporting "Real Risk of Significant Harm" threshold (s. 10.1) Notify individual at "first reasonable opportunity" (s. 12(2)) Data Residency Permitted with accountability Permitted with accountability (contractual controls vital) Individual Access Right to access personal information Right to access health records (specific HIC obligations) The Grey Zones Here's where healthtech companies frequently stumble: Grey Zone 1: The "Wellness vs. Health" Line A mental health app that provides CBT exercises and mood tracking? Likely PIPEDA. The same app if it integrates with a physician's practice and shares data for clinical purposes? Now you're in PHIPA territory. The product is the same—the regulatory treatment depends on the data flow and relationship. Grey Zone 2: Multi-Provincial Operations A healthtech company based in BC, selling to hospitals in Ontario and Alberta, storing data in AWS Canada (Montreal). Which law applies? The answer is often "multiple regimes simultaneously." Ontario patient data processed for an Ontario hospital triggers PHIPA. Alberta patient data triggers HIA. Your corporate practices as a BC company may still fall under PIPEDA for commercial activities that don't involve custodian relationships. Grey Zone 3: AI, Secondary Use & The Synthetic Data "Release Valve" Training machine learning models on clinical data introduces the most friction. PHIPA permits use of personal health information for research (with REB approval) or for "quality improvement" (QI), but the standards for de-identification remain a moving target. The IPC Ontario published De-Identification Guidelines for Structured Data in October 2025, but standards vary across provincial and territorial statutes. What one hospital considers "anonymized" another views as "re-identifiable risk." The distinction between de-identified data (direct identifiers removed, residual re-identification risk) and anonymised data (irreversibly non-identifiable) is not applied consistently across Canadian health institutions. The Strategic Pivot: Synthetic Data & Federated Learning Smart healthtech founders are bypassing this gridlock by changing the ask. Instead of requesting raw data transfer (which triggers high-risk reviews), they are leveraging Federated Learning and Synthetic Data. * "Data Behind Glass": You don't move the data. You bring the model to the data (Federated Learning). The raw PHI never leaves the hospital's firewall. * Synthetic Data: Use the local data to train a generator that creates synthetic records. These records retain the statistical correlations of the original dataset but contain no real patient information. * The Result: Synthetic data may fall outside PHIPA’s “custody” requirements if it is truly anonymised—irreversibly non-identifiable. But anonymisation is an exceptionally high standard, and de-identified data retains residual re-identification risk. The threshold matters: truly anonymised synthetic data can be aggregated and used for model training without per-row consent negotiations; de-identified data cannot. Practical Implications for Healthtech Founders 1. Product Architecture Decisions The regulatory framework should inform your data architecture early, not as an afterthought. If you know you'll sell into Ontario hospitals, design for PHIPA compliance from day one. This means: * Data residency controls (PHIPA doesn't mandate Canadian storage, but your hospital customers often will) * Audit logging sufficient for custodian accountability * Breach notification workflows that meet PHIPA's "first reasonable opportunity" standard (s. 12(2)) * Access and correction request handling 2. Contracting Strategy Health information custodians will require specific contractual protections before they can engage you. Expect: * Detailed schedules on permitted uses of personal health information * Breach notification obligations that exceed your standard DPA * Audit rights that go beyond typical enterprise agreements * Restrictions on subprocessing and offshore access If your standard MSA doesn't contemplate these requirements, you'll face friction in every hospital deal. Building PHIPA-aligned templates accelerates procurement. 3. Consent Architecture PIPEDA and provincial health statutes take different approaches to consent. PIPEDA emphasizes meaningful consent for collection, use, and disclosure, with limited exceptions. PHIPA operates on a "circle of care" model where consent is implied for treatment purposes within the custodian relationship. For healthtech products that span both regimes—say, a patient engagement platform that serves both clinical (PHIPA) and wellness (PIPEDA) functions—you need a consent architecture that satisfies both frameworks without creating friction for users. 4. Breach Response PHIPA's breach notification requirements are more prescriptive than PIPEDA's. A privacy breach involving Ontario patient data must be reported to the custodian (who reports to the Information and Privacy Commissioner) at the first reasonable opportunity — PHIPA does not prescribe a fixed timeline. Your incident response playbook needs to account for these obligations, including escalation paths and communication templates. Looking Ahead: Provincial Reform and AI Guidance The landscape is not static. In January 2026, the Information and Privacy Commissioner of Ontario (IPC) published guidance on the responsible development, procurement, and use of AI scribes in healthcare settings under PHIPA. The same month, the Office of the Information and Privacy Commissioner for British Columbia released parallel guidelines for healthcare organizations adopting AI scribe tools under PIPA. Both documents signal that regulators are addressing AI in health settings through guidance rather than legislative amendment — at least for now. With Bill C-27 (which included the Artificial Intelligence and Data Act) having died on the order paper in the previous Parliament, Canada still lacks a comprehensive AI regulatory framework. This means healthtech companies must navigate existing privacy legislation (PIPEDA, PHIPA, HIA, PIPA) and emerging regulatory guidance as the primary compliance architecture for AI-enabled health products. Crucially for West Coast companies, British Columbia does not have a private-sector health privacy statute equivalent to PHIPA. Private health clinics and healthtech companies in BC generally operate under PIPA, which is substantially similar to PIPEDA. BC's E-Health (Personal Health Information Access and Protection of Privacy) Act was enacted in 2008 to create a health information bank framework, but key provisions were never proclaimed into force. The distinct "custodian" model of Ontario does not map 1:1 to BC's private sector regime. The January 2026 BC IPC AI scribe guidance, however, signals that the regulator is actively shaping expectations for health-data handling under existing legislation. The Strategic View The healthtech companies that succeed in selling to Canadian health systems share a common trait: they've internalized that privacy compliance is part of the value proposition, not an obstacle to it. Hospitals and health authorities are under intense scrutiny. They face breach notification obligations, commissioner oversight, and public accountability for how they handle patient data. A vendor that can demonstrate genuine privacy competence—through architecture, documentation, and contracting—reduces their risk and accelerates procurement. That's the trust advantage. Privacy done well doesn't slow you down. It opens doors. --- ## Canada's Consumer-Driven Banking Act Is Now Law: What Every Fintech Needs to Know. URL: https://sarhandata.law/resources/canadas-consumer-driven-banking-act-is-now-law-what-every-fintech-needs-to-know Date: 2026-05-08 Category: Product Counsel After years of consultation, false starts, and cautious optimism, Canada has finally done it. On March 26, 2026, Bill C-15 — the Budget Implementation Act, 2025, No. 1 — received Royal Assent, formally enacting a comprehensive new Consumer-Driven Banking Act (CDBA). Canada's open banking framework is now the law of the land. For Canadian fintechs, this is the starting gun. The CDBA establishes the legal foundation for a consent-based, API-driven financial data ecosystem. The implementation details, however, including accreditation criteria, technical standards, liability frameworks, and consent rules, are still being worked out. That gap between law passed and regulations finalized is precisely where fintechs face the most consequential decisions. This post breaks down what the CDBA actually does, what it still leaves open, and the five legal questions every fintech should be asking right now. Update (July 2026): The draft Consumer-Driven Banking Regulations were published June 27, 2026 in Canada Gazette Part I, filling in many of the operational details discussed below — including accreditation pathways, security requirements, consent architecture, and record keeping. See our companion analysis: Canada's CDBA Draft Regulations Are Here: What Fintechs Need to Prepare For. What the law actually does The CDBA gives Canadians the legal right to direct their financial institutions to share their data with third-party providers of their choice. This ends screen scraping and the risky, credential-sharing workaround that roughly nine million Canadians currently use to access fintech apps. Standardized APIs replace it. The framework runs in two phases: Phase 1 — Read access (2026): Accredited entities can access deposit, investment, credit, and payment account data, with consumer consent. Phase 2 — Write access (mid-2027): Once the Real-Time Rail is live, the framework expands to payment initiation, account switching, and other transactional capabilities. The Bank of Canada is the primary supervisor — handling accreditation, maintaining a public registry of participating entities, supervising compliance, and enforcing the framework through suspension, revocation, compliance agreements, and administrative monetary penalties. The Department of Finance led the development of the regulations, and the Minister of Finance retains national security authorities over participating entities. That's the structure. Clean enough on paper. The harder question is what it means in practice. Here's the part most people are glossing over The CDBA is a legal foundation, not an operational framework. As of today, several things that actually matter are still undefined: * The list of mandated banks required to participate hasn't been published * The technical standards body hasn't been designated * Accreditation criteria and security standards for third-party providers are still being developed * The consent and authorization framework — how consent gets obtained, validated, and revoked — is still being finalized * Liability rules for breaches, unauthorized access, and fraud within the ecosystem remain unresolved The fintechs that treat this ambiguity as a reason to wait are going to find themselves retrofitting their compliance architecture at significant cost when the accreditation window opens. The ones that engage now will be building something defensible from the start. Five legal questions worth asking right now 1. Do you need to be accredited — and for what role? Any entity that wants to participate in consumer-driven data sharing needs to be a "participating entity" under the CDBA. For fintechs that aren't federally regulated financial institutions, that means going through a formal accreditation process with the Bank of Canada. But accreditation isn't uniform. Different roles — data recipients, data providers, intermediaries handling consent or authentication — will carry different compliance thresholds. Understanding which category maps to your business model is step one. Miss this and you're designing your compliance program for the wrong test. 2. Is your consent architecture ready for what's coming? Consent is the whole engine here. The CDBA requires express consumer consent before any data access. Consumers can understand, control, and revoke that consent at any time. That has direct implications for how your product works — your consent flows, data retention policies, terms of service, and user experience all need to be built around this. It also intersects with PIPEDA's updated data mobility provisions, also introduced through Bill C-15. The compliance surface is broader than it looks at first. Ask yourself: if the Bank of Canada audited your consent architecture today, could you show that every data access event was properly authorized? 3. Who's liable when something goes wrong? This is the most consequential and least resolved question in the framework. The emerging principle is that liability follows control: once a bank transfers data to an accredited third party through a mandated API, the bank's exposure ends at the point of transfer. The receiving entity owns what happens next. But the real complexity is in the chain. What happens when a breach involves multiple parties? What's the standard of care for a fintech holding consumer financial data? What happens when a consumer revokes consent but the data has already moved downstream? These questions will be answered in regulation — but the answers will be shaped by how the industry engages with the consultation process now. This is not the kind of thing you want to figure out after a breach. 4. How does the CDBA interact with your existing privacy obligations? The CDBA doesn't operate in isolation. It sits alongside PIPEDA — and in some places creates friction with it. Bill C-15 introduced amendments to PIPEDA specifically around the data mobility right. For fintechs, CDBA compliance obligations and PIPEDA obligations overlap in material ways: data minimization, purpose limitation, retention schedules, breach notification. If you're handling financial data accessed through the CDBA framework, you need a privacy compliance program that accounts for this intersection — not two separate frameworks running in parallel. 5. Is your data governance built for a regulated ecosystem? This is the sharpest break from the pre-CDBA world. Many fintechs operated in a grey zone — accessing financial data through screen scraping or informal bank arrangements, without a formal legal framework governing the relationship. That grey zone is closing. The CDBA will require participating entities to meet prescribed technical and security requirements, maintain records of data sharing activity, and operate within a governed, auditable framework. Your API documentation, data governance policies, vendor agreements, and security controls all need to be built to a regulated standard. For fintechs that have been operating informally, that's a real lift. For those that build this into their architecture now, it's a competitive advantage. What the smart fintechs are doing They're not waiting for every regulation to be finalized before they start preparing. They're conducting readiness assessments to map their current operations against the emerging framework. They're engaging with the Bank of Canada consultation process to understand — and where they can, influence — the direction of accreditation criteria and technical standards. They're reviewing consent frameworks, stress-testing liability exposure, and integrating CDBA work with their broader privacy compliance programs. The fintechs that win in Canada's open banking ecosystem won't just be compliant. They'll have built compliance into the product from the start. The CDBA is a structural redesign of how financial data moves in Canada. That creates real opportunity for fintechs that are positioned to participate on day one. The window to prepare is now. --- ## Party Roles in Data Processing Agreements: When Controller-to-Controller Makes Sense URL: https://sarhandata.law/resources/dpa-party-roles-controller-to-controller Date: 2026-01-19 Category: Product Counsel Every data processing agreement starts with a fundamental question: who is the controller and who is the processor? Most agreements will default to the familiar pattern: the customer is the controller and vendors are processors. Some of the most important data flows in modern business, however, operate on a controller-to-controller basis, and mischaracterizing these relationships creates legal risk and operational confusion. Understanding when controller-to-controller arrangements are appropriate is essential for companies navigating complex data ecosystems and trying to ensure that their chain of responsibilities is accordingly accounted for. The Core Distinction Controller: The organization that determines the purposes and means of processing personal information. The controller decides why data is collected and how it will be used. Under PIPEDA, this is the organization accountable to individuals for their data. Processor: The organization that processes personal information on behalf of a controller, according to the controller's instructions. The processor only executes the controller's decisions. Independent Controllers: Two organizations that each determine their own purposes for processing the same personal information. Neither acts on behalf of the other. Each is independently accountable. The distinction matters because it determines who bears accountability, what agreements are needed, and what obligations flow to individuals. When Controller-to-Controller Applies Several common business relationships are properly characterized as controller-to-controller rather than controller-to-processor: 1. Employer of Record (EOR) Services When you engage an EOR like Deel, Remote, or Oyster to employ workers in jurisdictions where you don't have an entity, the EOR isn't processing employee data on your behalf. The EOR is the employer. It determines how to process employee data for its own employment, payroll, benefits, and compliance purposes. You provide the EOR with information about the individual (who they are, what role, what compensation). The EOR then processes that data—and collects additional data—for its own purposes as the legal employer. This is two controllers: * You: Controller of business relationship data, work assignments, performance information * EOR: Controller of employment data, payroll processing, benefits administration, local compliance The agreement between you and the EOR should reflect this. It's not a DPA with you as controller and EOR as processor. It's a services agreement between two controllers, with provisions addressing each party's independent obligations. 2. GTM and Sales Intelligence Tools Platforms like Clay, Apollo, ZoomInfo, and similar GTM tools present an interesting case. When you use these tools, data flows in multiple directions: * Data you provide: You may upload your prospect lists, CRM data, or target account information * Data they provide: The platform provides enrichment data, contact information, intent signals from their own databases * Data they generate: The platform creates derived insights by combining your data with their data and third-party sources Is the GTM platform your processor? Not exactly. These platforms maintain their own databases, determine their own data collection practices, and use data from multiple customers to improve their products. They have independent purposes. The appropriate framing is often: * For data you upload: You're the controller, they process according to your instructions (processor relationship for this data) * For data they provide: They're the controller of their database, licensing you access (controller-to-controller data sharing) * For combined/derived data: This gets complex—the agreement needs to specify who controls what Many GTM tools use hybrid agreements that address both the processor and controller-to-controller elements. 3. B2B Data Partnerships When two companies share data to create joint value—combined analytics, shared insights, co-marketing—neither is typically acting as a processor for the other. Both have their own business purposes for the data. Examples: * A SaaS company sharing anonymized usage patterns with a research partner * Two companies in a strategic partnership sharing customer overlap data * A platform sharing seller data with a payment processor that uses it for fraud modeling These are controller-to-controller relationships where each party must ensure it has a lawful basis for its own processing. 4. Professional Services Firms Law firms, accounting firms, and consultants often function as independent controllers rather than processors. When you engage a law firm, you share information about your business, your employees, your counterparties. The law firm determines how to use that information to provide legal services—it applies its own professional judgment, maintains its own records, and has its own obligations. The law firm isn't processing data "on your behalf" in the processor sense. It's providing professional services that require it to make independent determinations about data handling. 5. Payment Processors and Financial Services Payment processors like Stripe, Adyen, or PayPal occupy an interesting position. When you integrate their services: * They process transaction data to execute payments (arguably processor-like) * They use transaction data for their own fraud prevention, risk modeling, and compliance (controller purposes) * They're subject to their own regulatory obligations that require independent data handling decisions Most payment processor agreements reflect this hybrid reality, with some data flows treated as processing on your behalf and others treated as independent controller activities. Why the Distinction Matters Accountability to Individuals Under PIPEDA and GDPR, controllers are accountable to individuals for how their data is handled. If you're the controller, you're responsible for ensuring lawful processing, responding to access requests, and notifying about breaches—even for data processed by your processors. In a controller-to-controller relationship, each controller is independently accountable for its own processing. You're not responsible for the other controller's compliance failures (though you may face reputational consequences from association). Consent and Legal Basis If you're a controller sharing data with a processor, your existing consent or legal basis covers the processor's handling (because they're acting on your behalf). If you're a controller sharing data with another controller, the receiving controller needs its own legal basis. Your consent doesn't automatically extend to their purposes. This is why controller-to-controller agreements include provisions about each party's compliance responsibilities. Instructions and Autonomy Processors act on controller instructions. Controllers make independent decisions. If you engage a vendor expecting them to follow your instructions precisely, and they're actually operating as an independent controller making their own determinations, you have a mismatch that creates risk. The vendor might use data in ways you didn't anticipate, and you won't have contractual recourse if those uses were within their legitimate controller purposes. Agreement Structure Processor agreements (DPAs) are inherently asymmetric—the controller directs, the processor obeys. Controller-to-controller agreements are between peers—each party has its own rights and obligations, and the agreement governs the interface between them. Structuring Controller-to-Controller Agreements When you've determined that a controller-to-controller relationship is appropriate, the agreement should address: 1. Data Flows Specify exactly what data moves in which direction: * What personal information does each party provide to the other? * What derived data is created, and who controls it? * What enrichment or combination occurs? 2. Purposes Each party's permitted purposes should be explicit: * What can Party A do with data received from Party B? * What can Party B do with data received from Party A? * Are there prohibited uses? 3. Legal Basis Each party should represent that it has a lawful basis for: * Disclosing data to the other party * Processing data received from the other party This doesn't mean each party guarantees the other's compliance—it means each party takes responsibility for its own. 4. Data Subject Rights How do the parties coordinate on individual requests? * If an individual asks Party A for access, and some of that data came from Party B, how is that handled? * If an individual asks Party A for deletion, does Party A notify Party B? 5. Security Obligations Even though neither party is directing the other's processing, both should commit to reasonable security measures. A breach at either party affects the shared data. 6. Breach Notification How do parties notify each other of incidents affecting shared data? What are the timelines and procedures? 7. Liability How is liability allocated for: * Breaches of the agreement * Third-party claims arising from each party's processing * Regulatory actions Controller-to-controller agreements often include mutual indemnification provisions rather than the one-way indemnities typical of DPAs. The Hybrid Reality Many vendor relationships don't fit neatly into controller or processor categories. The same vendor may be: * A processor for some data (customer data you upload for them to process according to your instructions) * A controller for other data (their own product improvement, aggregated analytics, fraud prevention) Sophisticated agreements acknowledge this reality with provisions that address each data flow according to its proper characterization. The agreement might include: * A DPA attachment for data processed on your behalf * Controller-to-controller terms for data the vendor processes for its own purposes * Clear delineation of which data falls into which category Practical Guidance When evaluating a new vendor or partner: 1. Map the data flows. What data goes where, and for what purposes? 2. Ask: Is this vendor acting on our instructions, or making independent determinations? 3. If the vendor has its own purposes for the data, it's at least partially a controller 4. Review their standard agreements—do they acknowledge their controller role, or do they try to disclaim all accountability? 5. Ensure the agreement structure matches the actual relationship Red flags: * A vendor that clearly operates as a controller but insists on a pure processor agreement (avoiding accountability) * An agreement that doesn't address the vendor's own uses of data * Lack of clarity about who handles data subject requests * Processor agreements with vendors that obviously make independent decisions about data For your own vendor agreements: If you're a SaaS company and your processing involves independent purposes (product improvement, aggregated analytics, ML training), be transparent about it. Controller-to-controller framing for those uses is more accurate—and more defensible—than trying to squeeze everything into a processor box. The Strategic Perspective The controller-processor framework made sense when data processing was simpler: you hired a vendor to do a specific task with your data, and they did exactly that. Modern data ecosystems are more complex. Data flows through multiple parties, gets enriched and combined, and serves multiple purposes. Companies that understand this complexity—and structure their agreements accordingly—reduce legal risk and build more sustainable data relationships. The goal isn't to avoid accountability by claiming everything is controller-to-controller. It's to accurately characterize each relationship so that accountability is properly allocated and everyone understands their obligations. When controller-to-controller is the right framing, use it. When processor is right, use that. And when the relationship is genuinely hybrid, build an agreement that reflects reality. --- ## Preparing for the Enterprise Sales Cycle: A Governance Playbook for Growth-Stage Companies URL: https://sarhandata.law/resources/enterprise-sales-governance-playbook Date: 2026-01-05 Category: Product Counsel Your product is ready. You've closed SMB customers and proven market fit. Now a Fortune 500 company wants to pilot. Suddenly you're drowning in security questionnaires, redlined DPAs, and procurement calls that feel like depositions. This is the enterprise sales cycle. For growth-stage companies, it's where deals go to die. The companies that break through aren't necessarily the ones with the best product. They're the ones that anticipated what enterprise buyers would ask for and built the answers into their operations before the RFP arrived. What Enterprise Buyers Actually Want Enterprise procurement isn't about checking boxes. It's about risk management. The buyer's security, legal, and compliance teams are asking a fundamental question: If we bring this vendor into our environment, what's our exposure? Their concerns cluster around several themes: Data Handling * Where does our data go? * Who at your company can access it? * What happens if there's a breach? * How do you handle data when we leave? Operational Security * How do you protect your systems? * What's your vulnerability management program? * Do you have incident response capabilities? * Who are your subprocessors? Compliance Posture * Do you meet industry standards (SOC 2, ISO 27001)? * Can you meet our regulatory requirements (PIPEDA, GDPR, sector-specific rules)? * Do you have appropriate insurance? Organizational Maturity * Is this company going to exist in two years? * Do they have the processes to support an enterprise relationship? * Can they scale with us? Every question on a security questionnaire traces back to one of these concerns. Understanding that helps you prepare answers that satisfy the underlying worry, not just fill in the blank. The Documents That Close Deals Enterprise deals require specific collateral. Having these ready—not scrambling to create them mid-deal—is the difference between a 60-day close and a 6-month slog. 1. Security Documentation * SOC 2 Type II Report: This is table stakes for enterprise SaaS. A Type I report (point-in-time) is a start, but buyers want Type II (period of time, typically 6-12 months). If you don't have it, be prepared to answer why and when. * Penetration Test Results: Annual third-party penetration testing, with a summary of findings and remediation. Buyers want to see you test your own defenses. * Security Whitepaper: A clear, well-organized overview of your security architecture, practices, and controls. This is technical documentation for security teams. 2. Privacy and Data Governance * Data Processing Agreement (DPA): Your standard DPA, drafted to be acceptable to sophisticated buyers without extensive negotiation. If every enterprise deal requires a ground-up DPA negotiation, you're creating friction. * Privacy Policy: Comprehensive, accurate, and specific about your data practices as a controller. Generic templates may signal that you're willing to say anything to get a deal rather than have done your due diligence. * Subprocessor List: Current list of all third parties who process customer data, with geographic locations. Buyers need this for their own compliance. * Data Flow Documentation: Where does data go? How does it flow through your systems? Can you explain it clearly? 3. Compliance Evidence * Compliance Mapping: If you operate in regulated sectors (healthcare, financial services), documentation showing how you meet applicable requirements. * Certifications and Attestations: SOC 2 (Type 2 if possible) report, ISO 27001 certificate, any sector-specific certifications. * Insurance Certificates: Cyber liability insurance is typically required. Have certificates ready to share. 4. Operational Documentation * Incident Response Plan: Documented procedures for security incidents, including notification timelines and communication protocols. * Business Continuity / Disaster Recovery: How do you maintain operations during disruptions? What are your recovery time objectives? * Vendor Management Policy: How do you evaluate and monitor your own vendors? Enterprise buyers care about your supply chain. The Security Questionnaire Strategy Security questionnaires are universally dreaded. Enterprise buyers send 200-500 question documents; vendors scramble to respond; both sides know the process is inefficient. But it's the game, and you need to play it well. Build a Response Library Don't answer each questionnaire from scratch. Build a master response library covering: * All questions from the common frameworks (SIG, CAIQ, VSA, HECVAT) * Your answers, with evidence references * Question mappings (different questionnaires ask the same thing differently) When a new questionnaire arrives, 80% of the answers should be copy-paste from your library. Your effort goes to the 20% that's unique. Pre-Position with a Security Package Before the questionnaire arrives, send your security documentation proactively: * SOC 2 report * Security whitepaper * Penetration test summary * Subprocessor list * Standard DPA This accomplishes two things: it signals maturity, and it often reduces the questionnaire burden. Security teams that see a SOC 2 report may abbreviate their review. Staff Appropriately Questionnaire responses require input from engineering, security, legal, and ops. Designate an owner—typically someone in security, compliance, or ops—who can coordinate responses and maintain the library. This person becomes your enterprise readiness quarterback. The DPA Negotiation Playbook Data Processing Agreements are where legal teams spend their energy. A poorly drafted or inflexible DPA creates friction that kills momentum. Start with a Strong Standard Your template DPA should: * Meet the requirements of PIPEDA, GDPR, and major US state laws * Include Standard Contractual Clauses for international transfers * Address breach notification with reasonable timelines * Define data retention and deletion obligations * Specify subprocessor notification and objection rights If your starting point is weak, every negotiation becomes a battle. Know Your Red Lines Certain requests are common and reasonable: * Specific breach notification timelines * Audit rights (with reasonable limitations) * Subprocessor restrictions tied to their compliance program * Data residency commitments if you can support them Certain requests are problematic: * Unlimited liability for data breaches * Audit rights with no advance notice or scope limitations * Requirements to maintain certifications you don't have * Data localization you can't technically support Know what you can accommodate, what you can negotiate, and where you have to hold firm. Document your rationale so your sales team can explain positions without escalating every issue. Empower Your Sales Team Sales should be able to handle routine DPA negotiations without involving legal on every call. This means: * Training on your DPA and common negotiation points * Authority to accept certain modifications (within defined parameters) * Clear escalation paths for issues outside their authority Your legal team should be closing edge cases, not reviewing every standard negotiation. Building the Muscle Enterprise readiness isn't a one-time project. It's an operational capability that compounds over time. Quarterly Cadence * Review and update security documentation * Refresh questionnaire response library * Update subprocessor list and DPA if needed * Analyze recent deals: What slowed them down? What can be improved? Feedback Loops Your sales and customer success teams hear what enterprise buyers care about. Create a mechanism for that feedback to reach whoever owns your security and compliance program. If the same objection comes up repeatedly, address it systematically. Investment Signals Enterprise buyers pay attention to how you invest. A SOC 2 audit isn't cheap. A dedicated security hire isn't cheap. These investments signal that you're building for the long term and taking their concerns seriously. The Trust Advantage Enterprise sales cycles are fundamentally about trust. The buyer is taking a risk by bringing you into their environment. Your job is to make that risk feel manageable. Companies that treat compliance as a checkbox create friction. Companies that treat it as a trust-building exercise accelerate deals. The difference: * Checkbox: "Here's our SOC 2 report, let us know if you have questions." * Trust-building: "Here's our SOC 2 report. I also want to walk you through our security architecture and how we'd handle an incident. What concerns does your team have?" The first response answers the question. The second response builds the relationship. When enterprise buyers trust you, procurement moves faster, negotiations are smoother, and you close. That's the competitive advantage that governance creates—not compliance for compliance's sake, but trust that translates into revenue. --- ## Building Sovereign AI: A Framework for Canada's Public Sector and Critical Infrastructure Leaders URL: https://sarhandata.law/resources/viss Date: 2025-10-15 Category: Reflections This article is an extension of the ideas I presented during my lunch remarks at the 2025 Vancouver International Security Summit (VISS). The conversation around building sovereign AI capabilities for Canada's public and critical infrastructure sectors is more urgent than ever, and this post offers a tangible governance framework for the leaders driving that mission. The global race for AI leadership is on. While many focus on computing power and algorithms, Canada's true, untapped advantage lies in our vast, high-quality public and private datasets. This is the fuel for the next generation of innovation in public services, economic growth, and national security. Yet, this strategic asset remains largely locked away, paralyzed by legitimate fears of privacy violations, security breaches, and ethical missteps. Public trust is low, and the risk of failure is high. A proactive governance framework doesn't inhibit innovation, however, it enables it. For Canada's public sector and critical infrastructure leaders, building a sovereign AI capability isn't just a technical challenge but primarily a governance one. This article provides a three-step framework to do it right. Step 1: Turning Data Liability into Your Greatest Asset It's not about having data; it's about having usable data. Before you can build, you must prepare the ground. This means legally and ethically engineering your datasets so they are safe and ready for AI and machine learning applications. * Go Beyond Anonymization: Under Canadian law, there are major differences between pseudonymized datasets, truly anonymized datasets, and de-identified datasets. True anonymization is the gold standard for unlocking sensitive health, transit, or civic data for broad research and model training, as it often removes the data from the scope of privacy law entirely. Aligning your technical teams on these definitions can substantially accelerate responsible and confident innovation. * Develop Data Trusts and Sandboxes: Create legally defined "sandboxes" where validated partners and researchers can access de-identified datasets for specific, public-benefit projects. This controlled environment allows for innovation without risking the integrity or security of the core dataset. Building data sharing frameworks that envision broader access and use can help reduce friction for secondary uses as they come up. * Rethink Consent for the AI Era: The traditional model of specific, informed consent is brittle and often impractical for the dynamic nature of AI. The modern, more defensible approach focuses on two pillars: * Reasonable Expectations: In accordance with new direction from the Federal Court of Appeal, aligning data use with what individuals would reasonably expect when they provided their information. This has been an unspoken cornerstone of Canadian privacy law and, as individual expectations re: data use are crystallizing over time, is paramount for maintaining public trust. * Demonstrable Accountability: Shifting the burden from individual consent to organizational accountability. This means being able to demonstrate that your systems are fair, secure, and used for their stated purpose, regardless of the consent obtained. Step 2: Vetting Your AI Supply Chain Most public sector AI will be procured, not built in-house. Remember: you're not just buying software; you're inheriting a supply chain of risk. It's important to understand the different layers of your AI supply chain, from the foundational model to the end-user application, and to contractually define ownership and risk at each stage. When you assess a vendor, differentiate between: * Primary Providers (Foundation Models): These are the base layers, like large language models. The key risks here are the provenance of their training data and inherent model biases that you will inherit. * Secondary Providers (AI-Driven SaaS): These vendors build applications on top of primary models, often incorporating complex data pipelines like Retrieval-Augmented Generation (RAG) or vector embeddings. The risks here multiply, involving how your data is processed, enriched, and secured at every step. 6 Key Questions to Ask Your Next AI Vendor: 1. "Where will our data live, and who can access it?" This covers data residency, security safeguards, and cross-border data flows. 2. "How was your model trained, and can you demonstrate bias mitigation?" This is essential for primary providers and helps you understand the risks you're inheriting. 3. "Can you explain how your application makes its decisions?" You need to push back against the "black box" excuse to meet your own transparency and accountability obligations. 4. "Who owns the outputs? The insights, reports, or new models generated using our data?" This is a critical IP question. Define ownership clearly in your contract to avoid giving away valuable derivative assets. 5. "What are our rights if we terminate the service? Can our data and the outputs be securely and verifiably deleted?" Ensure you have a clear exit path that doesn't lock you in or leave your data behind. 6. "Who is legally liable when the AI makes a harmful error?" Your contract must clearly allocate risk and provide indemnification for failures that are not your fault. Building on the AI Impact Assessment (as mentioned below), be sure to include specific indemnities for risks that may be foreseeable based on the use-case and/or model. Step 3: Preparing for When, Not If, Things Go Wrong Good governance shines brightest in a crisis. The final piece is establishing clear lines of human accountability before an AI system is deployed. This requires planning for a new class of novel, AI-specific incidents. * Appoint an "AI Accountable Executive": Just as you have a Chief Privacy Officer, a designated senior leader must be formally responsible for the performance, ethics, and impact of the organization's AI systems. This individual should be cross-functionally fluent and must be in touch with wide swaths of the organization. * Mandate AI Impact Assessments (AIA): Before any high-risk AI system goes live, a mandatory internal review must be conducted to proactively identify and mitigate risks related to bias, discrimination, and security. The federal government's own AIA is a useful starting point. * Create an "AI Incident Response Plan": A standard data breach plan is insufficient. This specialized playbook must address unique AI threats and failures, including: * Adversarial Attacks & Model Poisoning: A plan for malicious attempts to corrupt your training data or trick the model into producing harmful outputs. * Algorithmic Bias Discovery: A process for identifying, escalating, and remediating systemic biases that are discovered after deployment. * Cascading System Failure: A playbook for when an AI error causes significant, widespread operational disruption or public harm. Conclusion: From Governance to Advantage Building sovereign AI is a deliberate act of strategic governance, not just technological development. The initial three steps above provide a clear path forward. By embedding legal and ethical principles into our AI lifecycle from the start, we can turn a source of national anxiety into a source of enduring national advantage, building AI systems that are not only powerful but also trustworthy. Navigating the intersection of AI, data law, and public trust is complex. If your organization is starting this journey, I offer a complimentary 30-minute strategic call to discuss your specific challenges. --- ## BC Venture Funds: Which Structure Fits Your Strategy? URL: https://sarhandata.law/resources/venture-funds-in-bc Date: 2025-08-08 Category: Business Transactions British Columbia’s tech ecosystem is thriving. With this energy comes a new wave of ambition: visionary investors and operators are looking to launch their own venture capital funds to back the next generation of innovators. But before the first investment is made, a fund’s founders face a critical strategic decision that will define their fundraising, investment strategy, and operational reality. In B.C., there are two primary paths for structuring a venture fund: the traditional, flexible Limited Partnership (LP) model, and the provincially-incentivized Small Business Venture Capital Act (SBVCA) program. Choosing the right path isn’t just a legal formality; it’s the foundation of your fund’s identity. At Sarhan Data Law, we help our clients make this choice with clarity and foresight. Let’s break down both options. Path 1: The Traditional VC Fund – The Limited Partnership (LP) Model The LP model is the global standard for venture capital and private equity for a reason: flexibility and scalability. * How it Works: You, the fund manager, create a General Partner (GP) entity to manage the fund. Investors join as Limited Partners (LPs), contributing capital and limiting their liability. The relationship is governed by a comprehensive Limited Partnership Agreement (LPA). * The Core Advantage: Unrestricted freedom. The LP model allows you to define your own investment thesis. You can raise capital from accredited investors anywhere in the world—from Vancouver to New York to London—and you can invest in promising companies regardless of their location, stage, or industry. Your fund’s strategy is limited only by what you and your LPs agree to in the LPA. The engine of the traditional model is pure capital appreciation. Your success is measured by the returns you generate for your investors, free from government-imposed constraints. Path 2: The Provincial Advantage – The Small Business Venture Capital Act (SBVCA) The SBVCA program is a powerful tool created by the B.C. government to stimulate the local economy. It does this by offering a compelling incentive to investors. * How it Works: Your fund is set up as a B.C. corporation, registered with the province as a Venture Capital Corporation (VCC). When B.C.-based investors buy shares in your VCC, they receive a 30% provincial tax credit on their investment. Your VCC must then invest this capital into pre-approved "Eligible Small Businesses" (ESBs) based in British Columbia. * The Core Advantage: A supercharged fundraising tool. The 30% tax credit is a significant incentive that can dramatically de-risk the investment for B.C. residents and corporations. For a fund with a hyper-local B.C. focus, this can make raising your first fund significantly easier. The engine of the SBVCA model is the tax credit. It’s a powerful accelerator for attracting local capital, but it comes with a strict set of rules. The Strategic Crossroads: A Head-to-Head Comparison To put it simply, the traditional model offers freedom, while the SBVCA offers a powerful but constrained incentive. Think of it this way: the SBVCA program is like a government co-pilot that gives you a major boost, but it comes with a pre-approved flight plan limited to B.C. airspace. The traditional model gives you control of the cockpit to fly anywhere you see opportunity. Here’s how they stack up on key factors: Factor Traditional LP Fund SBVCA VCC Fund Investor Pool Global. You can fundraise from accredited investors and institutions anywhere. Local. Your primary fundraising advantage is with B.C. residents who can use the tax credit. Investment Mandate Flexible. Invest in any company, any geography, any stage that fits your thesis. Restricted. You must invest in B.C.-based "Eligible Small Businesses" in approved sectors. Geographic Focus Unrestricted. Support your companies as they grow and expand globally. Mandatory B.C. Focus. You risk non-compliance if a portfolio company moves its head office. Primary Incentive High Returns. Investors are motivated solely by the potential for significant capital gains. Tax Credit. The 30% tax credit is the main draw, lowering the effective risk for investors. Regulatory Body Primarily Securities Commissions. Primarily the B.C. Investment Capital Branch. Choosing the Right Path for Your Vision The right choice depends entirely on your fund's mission. * The SBVCA path is likely for you if: Your investment thesis is already hyper-focused on early-stage, B.C.-based companies in eligible sectors, and your target investors are primarily high-net-worth individuals and corporations in B.C. * The Traditional LP path is for you if: You envision a fund with a broader geographic scope, want the flexibility to invest in any sector or stage, and plan to target institutional investors from Canada and abroad. How Sarhan Data Law Can Help Choosing your path is just the beginning. At Sarhan Data Law, we provide the practical legal guidance to turn your vision into a reality. We assist fund managers with: * Strategic Structuring: Helping you select and form the right legal entity (LP or VCC) for your fund’s goals. * Document Drafting: Preparing the essential legal documents, including Limited Partnership Agreements, Subscription Agreements, and offering documents. * Securities Compliance: Navigating the complex prospectus and registration exemptions to ensure your fundraise is compliant. * Specialized Due Diligence: As a data-focused firm, we go one step further. We help you design and implement a sophisticated due diligence playbook to assess the data, AI, and privacy risks in your potential investments—a critical advantage in today's market. Starting a fund is a significant undertaking. Building it on the right foundation is the key to long-term success. Ready to explore the right path for your venture fund? Contact Sarhan Data Law today for a strategic consultation. --- ## Where is AI Liability heading? URL: https://sarhandata.law/resources/where-is-ai-liability-heading Date: 2025-04-21 Category: Product Counsel The rapid integration of artificial intelligence (AI) into commercial and public-sector operations has started to prompt legal scrutiny in Canada, particularly concerning liability for AI-driven decisions and misinformation. While the judiciary has not had a wholesome opportunity to consider the question of liability around AI, previous decisions regarding parallel technologies presents some options for where things are headed. Early Rumblings in Lower Tribunals The Moffatt v. Air Canada Decision In February 2024, the British Columbia Civil Resolution Tribunal (CRT) ruled that Air Canada was liable for negligent misrepresentation after its AI chatbot provided incorrect guidance to a customer regarding bereavement fare policies. The plaintiff, Jake Moffatt, had relied on the chatbot’s advice to purchase a full-price ticket under the assumption that he could later apply for a partial refund under Air Canada’s bereavement fare program. When the airline denied his refund request, citing a policy discrepancy between the chatbot’s statements and its official guidelines, Moffatt filed a claim for damages. The tribunal dismissed Air Canada’s argument that the chatbot constituted a “separate legal entity” exempting the company from liability. Tribunal member Christopher Rivers emphasized that businesses deploying AI systems must ensure the accuracy of all information disseminated through their platforms, whether static or dynamically generated. The ruling affirmed that organizations cannot delegate accountability for AI outputs to the technology itself, as doing so would undermine consumer protections and erode trust in automated systems. Continuation of Existing Principles The decision clarified several key points relevant to AI liability in Canada that mirror an employer's vicarious liability for the actions of its employees: 1. Duty of Care: Service providers owe a duty of care to consumers to ensure the accuracy of information provided through AI tools. 2. Standard of Care: Companies must implement reasonable safeguards to verify AI-generated content, including routine audits and disclaimers where necessary. 3. Causation: Reliance on AI misinformation can establish a direct causal link to financial or reputational harm, even if the error originates from machine learning algorithms. While the quantum of damages was minor (the tribunal awarded Moffatt damages totaling CAD 1,640.36, including partial reimbursement, interest, and tribunal fees), this outcome signals a growing judicial willingness to hold businesses accountable for AI failures, irrespective of the technology’s complexity or autonomy. Broader Implications for AI Governance Provincial Initiatives and Tort Law Adaptations In October 2024, the British Columbia Law Institute (BCLI) published a report advocating for tort law reforms to address AI-driven harms. The report rejected strict liability regimes, instead proposing a fault-based framework where plaintiffs must demonstrate that developers or deployers failed to meet a reasonable standard of care. Key recommendations include: * Evidentiary Adjustments: Courts should infer causation in cases where AI systems’ opacity prevents plaintiffs from tracing harm to specific design flaws. * Algorithmic Discrimination Remedies: Legislators should create civil remedies for biases embedded in training data or decision-making processes. These proposals align with the reasoning in Moffatt, emphasizing that existing negligence principles remain applicable but may require judicial flexibility to account for AI’s unique challenges. Beyond negligence, given the absence of legislation around liability for AI and while legislators consider specific AI-focused provisions, several other liability theories are starting to emerge in AI-related cases: * Copyright Infringement: The Canadian media lawsuit against OpenAI center on unauthorized use of copyrighted materials to train AI systems and several other cases are arising in the United States to determine the consequences of foundational models training on copyright data. * Product Liability: Traditional product liability concepts are being applied to AI systems, alleging defective design, failure to warn, and negligence. * Contractual Liability: Some cases involve breach of contract claims, particularly when AI systems fail to perform as promised or when terms of service are violated. * Class Action Liability: Where damage may be minor on an individual level but grand when considered broadly, AI developers may face class action lawsuits (especially as seen in more recent BC decisions). Industry Responses and Risk Mitigation Canadian businesses have accelerated efforts to implement AI governance frameworks. The federal government’s March 2025 release of a Guide for Managers of AI Systems provides practical steps for compliance with the ISED Voluntary Code of Conduct, including: * Regular audits of AI outputs for accuracy and bias. * Clear disclaimers informing users of AI-generated content’s limitations. * Human oversight protocols for high-stakes decisions, such as financial advisement or medical diagnostics. Major signatories to the Voluntary Code, including TELUS, CIBC and Intel, have pledged to integrate these measures into their AI deployment strategies. Emerging Jurisprudential Challenges As AI systems grow more sophisticated, courts will likely confront novel questions, such as: * Liability for Autonomous Actions: Whether developers can be held liable for unforeseeable AI behaviors arising from machine learning adaptations, including in sensitive areas like healthcare. * Third-Party Integrations: How liability should be apportioned when AI tools incorporate external data sources or APIs. * Cross-Border Disputes: Jurisdictional conflicts when AI systems operate across provincial or national boundaries. The ongoing CanLII v. Caseway AI and Toronto Star v. OpenAI cases, which address copyright infringement in AI training data, may further shape liability standards by clarifying the scope of “fair dealing” under Canadian law. Conclusion Canadian AI jurisprudence is developing and starting to affirm that traditional tort principles of negligence and misrepresentation apply to AI deployments. While legislative efforts like AIDA have stumbled, existing rulings provides immediate guidance for businesses: invest in AI governance, prioritize transparency, and assume liability for algorithmic outputs. As the technology evolves, Canada’s legal framework must similarly adapt, balancing innovation with accountability to safeguard public trust in an increasingly automated world. Future developments will hinge on collaborative efforts between policymakers, industry leaders, and the judiciary to create a cohesive strategy for AI accountability—one that learns from both the successes and shortcomings of early cases like Moffatt. Until then, organizations would be prudent to treat AI not as a shield against liability, but as a tool requiring diligent stewardship. --- ## Negotiating AI Contracts: Data, Training & Liability URL: https://sarhandata.law/resources/architecting-strategic-ai-service-agreements Date: 2025-04-14 Category: Business Transactions Artificial Intelligence is rapidly becoming foundational to the way enterprises deliver services. From optimizing operations to creating entirely new customer experiences, the potential is immense. As you integrate AI services into your ecosystem, a critical, often underestimated, challenge emerges: contracting. The agreements governing your AI partnerships are far more than legal formalities; they are strategic instruments that can significantly impact your innovation trajectory, risk exposure, and the long-term value derived from your data assets. Standard Service Agreements (SSAs) or boilerplate templates need deep changes to capture the unique complexities of AI. At Sarhan Law, we work at the intersection of technology, privacy, and commercial law. We see firsthand how crucial sophisticated AI contract negotiation and drafting are in 2025. Based on the evolving landscape, here are key strategic considerations every forward-thinking leader must address: Your Data is Your Strategic Asset In the AI era, data isn't just input; it's the fuel for insight and potentially the core of your competitive advantage. Your AI contracts must establish unambiguous data sovereignty from the outset. * Explicit Ownership: Best practice dictates clearly stating that all data provided by you (input) and generated specifically for you by the AI (output) remains your "sole and exclusive property." Don't settle for vague language. * Granular Definitions: Sophisticated agreements now differentiate between Customer Data, Personal Data, and Training Data, applying specific rules to each. This precision prevents accidental oversharing or misuse, particularly of sensitive personal information. Resist provider attempts to claim broad rights beyond service delivery, especially concerning raw output data. Navigating the Model Training Tightrope This is the crux of modern AI contracting – the "training data clause." Can the AI provider use your data to train or improve their underlying models? Allowing this can inadvertently leak sensitive patterns, enhance a tool used by competitors, or create complex compliance headaches. This isn't just a permission slip; it's a strategic decision with long-term consequences. The market offers a spectrum: * Full Prohibition: The default safe harbour – contractually forbidding any use of your data for model training. * Explicit Opt-In: Requiring your specific, written consent per use case before any training occurs, giving you maximum control. * Aggregated/Anonymized Use: Permitting training only on data demonstrably stripped of identifying features and aggregated. This requires rigorous technical validation and clear contractual safeguards. * Limited Purpose Use: Allowing training solely to improve the service for you, strictly prohibiting use for broader model enhancement. Consider adding model deletion requirements upon contract termination and audit rights to verify adherence – crucial mechanisms for maintaining control. Embedding Trust & Compliance AI systems operate within a complex web of privacy regulations (like PIPEDA, GDPR) and societal expectations of fairness. Your contracts must proactively address these: * Fortifying Privacy: Explicitly restrict or prohibit the use of personal data for model training due to compliance risks and the technical difficulty of "forgetting" data. * Mandating Fairness: Include provisions requiring the AI provider to implement bias detection and mitigation measures. This isn't just ethical; it protects your brand reputation and reduces legal liability arising from discriminatory AI outputs. De-Risking the Black Box: Clear Liability and Accountability When AI systems falter – generating incorrect information, infringing IP, or contributing to a data breach – ambiguity over responsibility is costly. Strategic contracts establish clear lines: * Explicit Provider Liability: Define the provider's accountability for data breaches originating from their service, AI-generated errors, infringement claims related to the AI's output, and regulatory fines tied to the service's function. * Indemnification: Secure appropriate indemnification clauses covering these AI-specific risks. * Monitoring & Explainability: Where feasible, include rights for ongoing monitoring and requirements for the provider to offer transparency or explainability regarding AI-driven decisions impacting your business. Architecting for Resilience: Termination and Data Governance Your AI partnerships will evolve. Clear exit protocols are essential for business continuity and preventing lock-in: * Defined Data Disposition: Mandate secure return or certified destruction of all your data upon termination, with clear timelines. * Model Management Clarity: Address what happens to AI models trained (even partially) on your data. While complex, especially for aggregated use, aim for decommissioning where your proprietary data was central to the training. The Strategic Imperative: Specialized Counsel for Specialized Technology Navigating the nuances of AI contracting – especially data rights, training permissions, and liability allocation – requires more than general legal knowledge. It demands a deep understanding of the technology, the evolving legal landscape, and the strategic implications for your business. Trying to adapt old templates or relying solely on provider paper creates unnecessary risk and can undermine the very value you seek from AI. How Sarhan Law Can Help: Whether you are a CIO integrating enterprise AI solutions or a Startup CEO building AI into your core offering, getting the contractual foundation right is paramount. Sarhan Law specializes in precisely this intersection. We help clients: * Negotiate complex AI service agreements with major providers, ensuring your rights and assets are protected. * Draft robust, future-proof standard AI service agreements for AI-first companies. * Advise on data privacy and ethical AI considerations within your commercial relationships. Don't leave your AI strategy vulnerable at the contractual level. Let's discuss how we can help you architect agreements that enable innovation while safeguarding your interests. Contact Sarhan Law today for a consultation on your AI contracting needs. --- ## Decoding Your Cyber Policy: 6 Critical Things to Review URL: https://sarhandata.law/resources/decoding-your-cyber-policy-6-critical-things-to-review Date: 2025-04-08 Category: Data Protection & Cybersecurity In today's digital world, cybersecurity threats are an unfortunate reality for enterprises across Canada. From ransomware attacks to sophisticated denial of service attacks, the risk for disruption and significant financial loss is high. Cybersecurity insurance is a vital backstop to mitigate these risks. However, simply having a policy isn't enough; understanding the details within that policy is important to ensure it aligns with your enterprise risk posture and incident response capabilities. As a firm dedicated to the intersection of law, technology, and security, we frequently advise clients on navigating the complexities of cyber risk. Here are six critical areas every enterprise should deeply understand within their cybersecurity insurance policy: 1. The Data Exclusion Dilemma: Why Traditional Insurance Often Falls Short Traditional business insurance policies, like Commercial General Liability (CGL) or professional liability insurance, may include exclusions for covering cyber incidents. Many businesses mistakenly assume their general liability coverage extends to digital risks. However, data exclusion clauses, which are becoming more common and strictly interpreted in standard CGL and similar traditional policies, can specifically carve out cybersecurity coverage. Court decisions have progressively clarified this gap, solidifying the understanding that traditional policies were not built for the digital age. The 2021 Ontario Court of Appeal case, Family and Children's Services of Lanark, Leeds and Grenville v. Co-operators General Insurance Company, provides an illustration. There, the Ontario Court of Appeal found that found that an exclusion related to the "display or distribution of data on the Internet" effectively nullified the insurer's duty to defend claims arising from a cyber breach under that particular policy framework. This ruling serves as a powerful warning for businesses to review data exclusion clauses within their existing policies. Depending on your risk profile and business, this could be a sign to seek a separate, dedicated cybersecurity insurance policy. Such policies are specifically designed to address the unique liabilities and costs associated with data breaches and other cyber incidents, filling the void left by exclusions in more traditional insurance products. Meticulous review isn't just about understanding your cyber policy; it's also about recognizing the limitations explicitly written into your general liability coverage regarding data-related risks. 2. Meeting the Bar: Minimum Security Requirements Cyber insurers don't issue policies into a vacuum; they expect baseline security controls. Nearly all policies stipulate minimum required security controls as a condition of coverage. These aren't suggestions – they are contractual obligations assessed at application and renewal. Failure to implement or maintain these controls can be grounds for claim denial. Common requirements include: * Multi-Factor Authentication (MFA): Especially for remote access and privileged accounts. * Employee Cybersecurity Training: Regular awareness programs. * Reliable Data Backups: Regularly tested and stored securely (often offline/immutable). * Identity Access Management (IAM): Controlling user permissions. * Data Classification: Understanding and protecting sensitive data. Failure to implement and consistently maintain these measures can lead to claim denial or policy cancellation. It's essential to meet these requirements before finalizing your insurance coverage. Treat these requirements as auditable controls and map your existing security stack and processes directly against the policy's stipulations. Maintain documentation and evidence of compliance. Ensure your security roadmap aligns with insurer expectations, which often evolve with the threat landscape. 3. Scrutinize Coverage Definitions, Sub-limits, and Exclusions The devil is truly in the details of what constitutes a covered "event" or "loss." When you get your policy, ensure you know exactly what it covers and what it doesn't: * Definitions: How does the policy define a "cyber incident," "wrongful act," "data breach," or "network interruption"? Does it align with your operational reality? * Coverage Areas: Confirm coverage for key risks: network security/privacy liability, breach response (forensics, notification, credit monitoring, legal), business interruption (BI), data recovery, cyber extortion/ransomware payments, regulatory defence/fines. * Sub-limits: Be aware of lower limits for specific coverages (e.g., ransomware payments, regulatory fines, social engineering fraud). Are these adequate given your risk profile? * Exclusions: Pay close attention to what's not covered. Common exclusions include acts of war/terrorism (interpretations vary), failures attributed solely to internal negligence without an external trigger, loss of certain unencrypted data, or incidents pre-dating the retroactive date. Work with your risk management and legal teams to model potential incident scenarios against the policy language. Identify critical risks specific to your enterprise (e.g., environment impacts, large-scale regulatory exposure under PIPEDA/GDPR/CCPA if applicable) and confirm adequate coverage or negotiate endorsements. 4. Understand Incident Response Integration When an incident strikes, speed and expertise are critical. Your policy dictates how incident response (IR) resources, such as legal counsel and forensic investigators, are engaged. Many insurers require the use of pre-approved "panel" vendors. While these firms are vetted, they may not have specific expertise relevant to your industry or technology stack, or they may conflict with your established IR relationships. Review the policy's requirements regarding IR vendors before an incident. If you have preferred, trusted legal and forensic partners, negotiate with the insurer to have them pre-approved and formally added to the policy at the time of purchase or renewal. Failure to do this can lead to delays, suboptimal response, or disputes over cost coverage if you engage non-panel vendors during a crisis. Also, clarify the "Duty to Defend" provisions – understand when the insurer's obligation to cover legal defence costs triggers and any conditions attached (like reimbursement undertakings). There are circumstances where you must initially incur the cost of IR and only later determine claim eligibility. 5. Clarify Coverage Timelines Policies contain critical time limitations. The Retroactive Date typically excludes coverage for wrongful acts occurring before this date (often the inception date of the first policy with that insurer). This prevents coverage for long-standing, pre-existing vulnerabilities. If available, "Prior Acts Coverage" can mitigate this gap. For Business Interruption (BI), understand the Waiting Period (e.g., 8-12 hours of downtime before coverage begins) and the Indemnity Period (the maximum duration coverage applies, e.g., 90-180 days). Confirm the retroactive date and assess potential exposure related to historical activities or inherited risks (e.g., from M&A). For BI, ensure the waiting period is realistic for your recovery plan and the indemnity period is sufficient to cover a potentially prolonged recovery from a major incident. 6. Verify Coverage for Modern Threats Threat vectors evolve. Ensure your policy adequately addresses prevalent modern attacks: * Social Engineering Fraud: Attacks manipulating employees into transferring funds or divulging credentials may be excluded or heavily sub-limited in standard policies. Specific endorsements are often required. * Third-Party/Supply Chain Risk: Incidents originating from compromised vendors or service providers are increasingly common. Review how your policy addresses liability and losses stemming from these third-party relationships. Explicitly check for social engineering fraud coverage and its limits. Understand policy language regarding incidents caused by third-party providers your enterprise relies upon. Advocate for endorsements if coverage gaps exist for these high-probability risk vectors. Conclusion: Proactive Partnership for Optimal Protection Your enterprise cybersecurity insurance policy is a strategic asset, but only if its intricacies are fully understood and aligned with your security posture and risk profile. Actively participating in the policy review process alongside legal, risk management, and your insurance broker can be really helpful to develop a cohesive strategy for cybersecurity. Treat the policy not just as a financial backstop, but as another layer in your comprehensive security strategy that requires ongoing validation and alignment. Proactive diligence ensures that when a crisis hits, your insurance coverage performs as expected, supporting effective response and recovery. --- ## PIPEDA: A Resilient Framework for Privacy in the AI Era URL: https://sarhandata.law/resources/pipeda-a-resilient-framework-for-privacy-in-the-ai-era Date: 2025-03-31 Category: Product Counsel The Personal Information Protection and Electronic Documents Act (PIPEDA) is Canada's federal privacy law governing the collection, use, and disclosure of personal information by private sector organizations during commercial activities. As technological advancements like artificial intelligence (AI) reshape industries, PIPEDA's foundational principles have demonstrated adaptability and resilience to emerging challenges. This post delves into PIPEDA's ten principles, provincial adequacy rules, and its capacity to remain relevant amid rapid technological change. The 10 Principles of PIPEDA PIPEDA is built on ten Fair Information Principles, which serve as a robust framework for protecting personal information: 1. Accountability: Organizations must designate individuals responsible for ensuring compliance with PIPEDA. They are required to implement privacy management programs and policies to safeguard personal information. 2. Identifying Purposes: Organizations must clearly identify and document the purposes for collecting personal information before or at the time of collection. Transparency is key, especially when purposes evolve. 3. Consent: Individuals must give informed consent for the collection, use, or disclosure of their personal information, except where inappropriate (e.g., legal requirements). 4. Limiting Collection: The collection of personal information must be restricted to what is necessary for identified purposes. Fair and lawful means are mandatory. 5. Limiting Use, Disclosure, and Retention: Personal information can only be used or disclosed for the original purposes unless consent is obtained or legally required. Retention must align with necessity. 6. Accuracy: Organizations must ensure that personal information is accurate, complete, and up-to-date to fulfill its intended purpose effectively. 7. Safeguards: Security measures must protect personal information from unauthorized access, disclosure, or misuse. Safeguards should correspond to the sensitivity of the data. 8. Openness: Organizations are required to make their privacy policies and practices readily accessible to individuals. 9. Individual Access: Individuals have the right to access their personal information upon request and challenge its accuracy or completeness. 10. Challenging Compliance: Individuals can challenge an organization’s adherence to PIPEDA principles through established procedures. These principles collectively empower individuals while ensuring organizations maintain high standards for privacy protection. Provincial Adequacy Rules While PIPEDA applies across Canada, certain provinces have enacted privacy laws deemed "substantially similar" to PIPEDA: * Québec, British Columbia, and Alberta have comprehensive private-sector privacy laws that exempt organizations operating within these provinces from PIPEDA's direct application. * In provinces like Ontario, New Brunswick, Nova Scotia, and Newfoundland and Labrador, legislation governing health information has also been deemed substantially similar for specific entities such as healthcare providers. This "patchwork" of provincial laws requires organizations operating interprovincially or internationally to navigate both federal and provincial regulations carefully. Québec's recent enactment of Law 25 exemplifies evolving provincial privacy standards. It mandates proactive measures like privacy impact assessments for activities involving AI tools and imposes transparency requirements for automated decision-making systems. These developments highlight how provincial laws complement PIPEDA by addressing emerging technologies and can introduce new specific requirements from private sectors actors. Resilience Amid Technological Change Over time (and especially with the death of Bill C-27), PIPEDA has proven adaptable to the times. That stems from its principles-based approach rather than rigid prescriptive rules. This flexibility allows it to address new challenges posed by technologies like AI without requiring constant legislative amendments: * The principle of reasonableness ensures that organizations collect, use, or disclose personal information only in ways that a reasonable person would consider appropriate under the circumstances—this standard inherently accommodates technological advancements. * While PIPEDA does not explicitly regulate AI tools, its provisions apply broadly to any activity involving personal information, including AI-driven data processing. * Safeguards against inappropriate uses of personal data—such as profiling leading to discriminatory treatment—are particularly relevant in AI contexts where biases can arise from algorithmic decision-making. Moreover, PIPEDA’s emphasis on transparency (e.g., identifying purposes) aligns well with emerging global trends demanding accountability in AI systems. For instance, organizations deploying AI tools can leverage PIPEDA’s framework to ensure compliance with both domestic privacy laws and international standards. PIPEDA has also consistently obtained adequacy status under the General Data Protection Regulation (GDPR) in Europe, enabling seamless data transfers between the EU and Canada. Since the European Commission first recognized PIPEDA as adequate in 2001, this status has been upheld through periodic reviews, most recently in January 2024. Adequacy ensures that personal data can flow from the EU to Canadian organizations without requiring additional safeguards, such as standard contractual clauses or binding corporate rules, simplifying compliance for businesses operating across borders. Conclusion PIPEDA remains a resilient legislative framework capable of addressing privacy concerns in an era dominated by technological innovation. Its principles-based approach provides flexibility while maintaining robust protections for individuals’ rights. As AI continues to transform industries, PIPEDA’s focus on accountability, consent, transparency, and safeguards ensures it adapts effectively without losing relevance. Provincial adequacy rules further strengthen Canada’s privacy landscape by introducing tailored requirements that complement PIPEDA’s federal scope. Together, these frameworks create a cohesive system that balances innovation with privacy protection—an essential consideration as businesses increasingly adopt AI-driven solutions. Organizations navigating Canada’s privacy laws should view PIPEDA not as a static regulation but as a dynamic tool capable of evolving alongside technological progress while safeguarding fundamental rights. --- ## New Frontiers in Canadian Privacy Law URL: https://sarhandata.law/resources/new-frontiers-in-canadian-privacy-law Date: 2025-03-24 Category: Product Counsel Two landmark decisions in 2024, Clearview AI Inc. v. Information and Privacy Commissioner for British Columbia (2024 BCSC 2311) and Canada (Privacy Commissioner) v. Facebook, Inc. (2024 FCA 140), provide critical guidance for organizations navigating privacy and AI regulation. These rulings establish new compliance paradigms for extraterritorial jurisdiction and digital consent frameworks. Extraterritorial Reach: Clearview’s Precedent In Clearview AI, the BC Supreme Court extended provincial privacy law to foreign entities without physical presence in British Columbia. The court found jurisdiction under BC’s Personal Information Protection Act (PIPA) based on two factors: (1) that Clearview AI was marketing services to BC clients; and (2) that Clearview was collecting facial recognition data from BC residents’ publicly available online images This “real and substantial connection” test (applied to privacy law for the first time) signals that any organization harvesting data from BC residents may face PIPA compliance obligations, regardless of corporate headquarters or server locations. The Court also rejected Clearview’s reliance on the “publicly available information” exemption, emphasizing that bulk scraping of biometric data creates disproportionate risks of harm. Consent Revolution: Facebook’s PIPEDA Reckoning The Federal Court of Appeal’s Facebook decision redefined consent standards under PIPEDA, addressing the Cambridge Analytica scandal. Key holdings included: A. Meaningful Consent Requires Clarity: An objective “reasonable person” standard ensures that consent validity depends on what a hypothetical informed user would understand, not subjective interpretations As part of this standard, the Federal Court of Appeal clarified the following prohibited practices: * Buried disclosures in lengthy privacy policies (Facebook’s 4,300-word Data Policy failed this test) * Passive consent through default sharing settings * Vague references to third-party data use in adhesion contracts This holding pushes companies to innovate with their digital consent frameworks online towards a model of consent as a reasonable user may expect. B. Unshakable Safeguarding Obligations: The Court rejected Facebook’s argument that safeguarding responsibilities ended when data reached third-party apps. Key failures included: * Ignoring “red flags” from apps requesting excessive data * Failing to audit developers’ compliance with privacy policies * Creating an unmanageable ecosystem of 40,000+ apps while contracting away accountability This spelling away of accountability points to a regulatory trend of shifting the onus on consumers and data subjects to protect their data through consent towards a model in which data controllers have broader obligations towards their data subjects. Cross-Canada Enforcement Landscape These cases, taken together, drive at a compliance baseline with three key features: 1. No Digital Exceptionalism: Traditional territorial analysis adapts to borderless data flows 2. Consumer-Centric Standards: Complexity no longer excuses obscurity – privacy notices must facilitate genuine understanding 3. Chain of Custody Accountability: Data controllers remain responsible for downstream uses, even by third parties Building Future-Proof Compliance For enterprises and organizations working with personal information, these decisions demand proactive strategies: * Revise jurisdictional assessments to consider data subject residency rather than corporate footprints * Redesign consent workflows using plain-language disclosures tested against the “reasonable person” standard * Implement AI governance frameworks that document safeguarding measures for training data and model outputs Organizations should treat these cases as warning shots across the bow – Canadian regulators now wield sharpened tools to enforce privacy rights in algorithmic systems. The path forward requires embedding privacy-by-design into AI development lifecycles, ensuring compliance keeps pace with technological innovation. --- ## VIPSS 2025: At the Nexus of Privacy, Security, and Emerging Tech URL: https://sarhandata.law/resources/vipss-2025-at-the-nexus-of-privacy-security-and-emerging-tech Date: 2025-03-17 Category: Reflections Last week, I had the opportunity to attend the Victoria International Privacy & Security Summit (VIPSS) 2025. The event was a convergence point for a diverse and engaged group of cybersecurity professionals, privacy experts, legal minds, and representatives from various public sector agencies. There was a ton of urgent collaboration at the intersection of technology, regulation, and human rights in our increasingly digital world. Several themes emerged throughout the sessions, painting a picture of a future demanding proactive adaptation and cross-disciplinary partnership. The Twin Revolutions: AI and Quantum Computing on the Horizon A sense of overwhelming technological acceleration permeated most sessions. Folks particularly flagged the convergence of Artificial Intelligence (AI) and quantum computing. As we experience, our daily encounters with AI breakthroughs only foreshadow a future arriving faster than anticipated. This rapid advancement brings the prospect of "Q-Day"—the day quantum computers become powerful enough to break current classical encryption standards—into sharper focus. Several session speakers talked about the profound implications Q-Day holds for global security, financial systems, and fundamental data privacy. The discussion wasn't just theoretical; it centered on actionable strategies for transitioning to quantum-resistant cryptographic standards. The panel stressed the necessity of starting now to understand the timelines, develop preparedness frameworks, and foster collaborative approaches to mitigate these existential risks while simultaneously exploring the potential benefits of quantum advancements. The consensus was clear: proactive planning for a secure quantum future is no longer optional, but imperative, especially as AI development continues its exponential trajectory, potentially creating a "twin revolution" scenario that will reshape our technological landscape. Bridging the Silos: The Imperative of Privacy and Security Collaboration There was also a recurring theme around the need for better collaboration between privacy and security professional. The traditional silos are becoming untenable. As data collection and usage become more complex, particularly fueled by AI, robust cybersecurity practices like the principle of least privilege and zero-trust architectures are not just security measures but also becoming essential components of effective privacy management. One of the most compelling keynotes vividly talked about the overwhelming complexity defenders face, grappling with nuanced controls across sprawling hybrid environments—from traditional data centers to cloud, virtual, containerized, and serverless architectures. This complexity is the enemy of effective security, creating vulnerabilities that adversaries exploit. Based on the risks of complexity, organizations must change how they defend, adopting dynamic, adaptable strategies. This perfectly aligns with the need for cross-functional teams where privacy and security insights inform each other, enabling faster, more iterative development cycles. Furthermore, there is potential for AI to act as an "on-the-job coach," to help professionals quickly grasp concepts from adjacent disciplines. Canadian Privacy Landscape: Stalled Reforms and the Search for Pressure Points While the technological frontiers are advancing rapidly, the summit also spoke critically on the state of Canada's privacy framework, revealing significant challenges and a sense of frustration. A key takeaway, echoed in multiple sessions, is that many organizations lack sufficient pressure – either regulatory or societal – to truly innovate and invest meaningfully in privacy-enhancing practices. Privacy lawyers mourned the likely failure of the federal government's Digital Charter Implementation Act and the fact that this leaves Canada's private sector privacy law, PIPEDA, as the primary legislation governing AI development and deployment – a potential gap given the technology's proliferation. The discussion explored the implications of this legislative inertia and debated necessary steps forward for any future government. This legislative vacuum exists alongside a rising tide of litigation. Increases in cyberattacks and evolving legal theories (potentially allowing damages without proof of specific harm) are fueling class action activity, making robust risk mitigation strategies crucial for organizations. Against this backdrop, BC Information and Privacy Commissioner Michael Harvey's Keynote Address on "Consent in a Big Data Age" felt timely. Harvey argued against the notion that the consent model is broken, advocating instead for its reinforcement as a rights-centric keystone of privacy law, especially vital for placing guardrails around AI data collection. While acknowledging the need for supplementary legal authorizations, he stressed that prioritizing a robust, rights-respecting consent framework can build trust and empower individuals without unduly hindering innovation. Collectively, these sessions painted a picture where significant change is needed. Without stronger, more punitive regulatory frameworks or a significant societal shift in demanding better privacy practices – potentially driven by public education – meaningful progress and investment in privacy innovation may lag. Conclusion VIPSS 2025 was a thought-provoking and energizing summit. It highlighted the interconnectedness of privacy, security, AI ethics, and looming technological shifts like quantum computing. The key takeaways underscore the urgency for organizations to break down internal silos, foster deep collaboration between privacy and security teams, proactively prepare for quantum threats, and champion robust, rights-based approaches to data governance. While facing challenges like stalled legislative reform, the collective expertise and commitment shown at VIPSS provide optimism that through continued dialogue, strategic planning, and potentially increased regulatory or public pressure, we can navigate the complexities ahead and build a more secure and privacy-respecting digital future. --- ## AI Governance Counsel for Vancouver Businesses URL: https://sarhandata.law/services/ai-governance-counsel-vancouver Date: 2026-08-17 Category: AI Governance Legal Services Vancouver-based AI governance legal counsel for businesses buying or deploying AI. The service covers enterprise AI MSA review and negotiation, operational governance programs, privacy and vendor risk, procurement controls, incident readiness, and board oversight. --- ## Privacy Policy URL: https://sarhandata.law/privacy Date: 2026-08-17 Category: Legal Our privacy policy outlines how Sarhan Data Law collects, uses, and protects personal information when visitors use sarhandata.law, including data handling for contact form submissions and newsletter subscriptions. --- ## How We Work URL: https://sarhandata.law/how-we-work Date: 2026-08-17 Category: Firm Operations Our structured approach to legal services: subscription engagements for ongoing counsel, project-based work with defined scope and deliverables, and transaction support for M&A, funding rounds, and strategic partnerships involving data or technology assets. Purpose-built workflows and automation reduce time-to-delivery, structured processes create predictable outcomes, and scoped engagements with transparent pricing eliminate open-ended hourly billing anxiety. --- ## Enterprise AI MSA Playbook URL: https://sarhandata.law/playbook Date: 2026-08-17 Category: AI Governance A practical legal resource for negotiating AI Master Service Agreements. Clause library, risk frameworks, and negotiation guidance for AI SaaS founders, in-house counsel, and external lawyers, distilled into a free 55-page downloadable playbook plus a chapter-by-chapter guide at /playbook/guide. --- ## AI Governance Framework for Law Firms URL: https://sarhandata.law/ai-governance-for-law-firms Date: 2026-08-17 Category: AI Governance Free AI governance reference briefs for Canadian law firms: a four-pillar AI governance framework and a use-case register with human-in-the-loop standards for legal AI applications, helping firms adopt AI tools responsibly. --- ## AI MSA Playbook Chapter Guide URL: https://sarhandata.law/playbook/guide Date: 2026-08-17 Category: AI Governance Enterprise AI MSA Playbook — a practical guide to negotiating AI SaaS master service agreements. Each chapter covers a distinct battleground with vendor/buyer perspectives, red flags, and sample clauses. --- ## The Pilot-to-Production Bridge URL: https://sarhandata.law/playbook/guide/pilot-to-production Date: 2026-08-17 Category: AI Governance How to structure AI pilot agreements so they bridge cleanly to a production MSA — covering evaluation criteria, data access scoping, and exit/upgrade provisions. --- ## Battleground 1 — AI Definitions URL: https://sarhandata.law/playbook/guide/ai-definitions Date: 2026-08-17 Category: AI Governance The definitional battleground in AI MSAs: how "AI", "Customer Data", "vector embeddings", and "derivative data" are scoped determines downstream IP and liability exposure. --- ## Battleground 2 — Reps, Warranties & AI Accountability URL: https://sarhandata.law/playbook/guide/ai-warranties-accountability Date: 2026-08-17 Category: AI Governance Representations, warranties, and accountability clauses specific to AI SaaS vendors: governance commitments, bias disclosures, and human-oversight warranties. --- ## Battleground 3 — Risk Allocation URL: https://sarhandata.law/playbook/guide/ai-risk-allocation Date: 2026-08-17 Category: AI Governance Risk allocation mechanics in AI contracts: liability caps, indemnification triggers, consequential damage carve-outs, and minimum dollar floors for AI-specific losses. --- ## Battleground 4 — SLAs URL: https://sarhandata.law/playbook/guide/ai-sla Date: 2026-08-17 Category: AI Governance SLA terms for AI SaaS: model availability, output quality metrics, token latency commitments, and remedies when AI performance degrades. --- ## Battleground 5 — Security URL: https://sarhandata.law/playbook/guide/ai-security Date: 2026-08-17 Category: AI Governance Security schedules for AI vendors: zero data retention (ZDR) provisions, sub-processor controls, prompt injection obligations, and AI-specific audit rights. --- ## Battleground 6 — IP, Licensing & Feedback Loops URL: https://sarhandata.law/playbook/guide/ai-ip-licensing Date: 2026-08-17 Category: AI Governance Intellectual property and licensing in AI MSAs: output ownership, training prohibitions on customer data, feedback loop licensing, and derivative data ownership. --- ## Battleground 7 — Termination & Exit URL: https://sarhandata.law/playbook/guide/ai-termination-exit Date: 2026-08-17 Category: AI Governance Termination and exit provisions for AI contracts: data return obligations, deletion certificates, model removal triggers, and survival clauses. --- ## The Regulatory Overlay URL: https://sarhandata.law/playbook/guide/ai-regulatory-overlay Date: 2026-08-17 Category: AI Governance How the EU AI Act, Canadian AI procurement policy, PIPEDA, and Colorado SB24-205 layer onto commercial AI MSA terms — practical contractual translations. --- ## The AI-Native Redline Workflow URL: https://sarhandata.law/playbook/guide/ai-redline-workflow Date: 2026-08-17 Category: AI Governance A deal-side negotiation workflow for AI MSAs: how to triage vendor paper, sequence redlines, and use AI-native tools to accelerate enterprise deal cycles. --- ## Chapter 3: The Pilot-to-Production Bridge URL: https://sarhandata.law/playbook/guide/pilot-to-production Date: 2026-08-17 Category: Enterprise AI MSA Playbook Most enterprise AI relationships start with a pilot — $15K, three months, a subset of users. If the pilot agreement is silent on what happens next, the deal stalls at graduation. Most enterprise AI relationships do not start with a $150K annual commitment. They start with a pilot. The vendor sends a short-form pilot agreement — a purchase order, a lightweight evaluation license, a click-through trial. It has none of the AI-specific hooks: no derivative definition, no training prohibition, no exit provisions for model changes. The pilot goes well. Procurement moves to the full MSA. Forty-seven redlines appear. The deal that worked in practice cannot survive the paper it needs for production. Four to six weeks of legal negotiation follow. The champion inside the enterprise loses momentum and the pilot's goodwill evaporates. The fix is negotiating the production MSA now and attaching a Pilot Schedule that carves out production-level obligations during the evaluation period. The production MSA is the base and both sides negotiate it in full ahead of the pilot — definitions, IP, training restrictions, liability caps, exit provisions. Once aligned, a Pilot Schedule is attached that specifies certain provisions are modified during the evaluation period only. When the pilot graduates to production, the carve-outs expire and the underlying MSA activates in full. The incentives align. The vendor gets the production MSA negotiated while the relationship is new and goodwill is high. The buyer gets binding commitments on the things that matter — derivatives, no-training, sub-processor flowdown, exit — without having to renegotiate them when the pilot succeeds. The Pilot Schedule defers four operational carve-outs: (1) SLA credits — no credits during pilot, though production terms are agreed and activate at graduation; (2) data in scope — pilot-eligible data only, non-sensitive, non-personal unless anonymized; (3) liability caps — modified to a pilot-period floor bridging the gap between pilot fees and enterprise-data risk; and (4) warranties — scoped to pilot documentation only, with the production warranty package negotiated and held in reserve. Graduation triggers define what 'graduation' means: auto-graduation when the pilot period expires and the customer continues; a usage threshold such as 1,000 API calls per month or 50 users; or express written notice from either party. At graduation, the Pilot Schedule terminates and the full MSA activates. The transition is a single sentence in an email, not six weeks of redlines. --- ## Battleground 1: AI Definitions URL: https://sarhandata.law/playbook/guide/ai-definitions Date: 2026-08-17 Category: Enterprise AI MSA Playbook Nobody raises their voice over definitions. That is what makes this battleground dangerous. You lose it in silence at the top of the agreement, and the loss cascades into ownership, training rights, and data exit. Legacy SaaS definitions cover what you upload: documents, files, data sent to the platform. That worked when the product was a database with a UI. AI products are different. Your input passes through a pipeline — it becomes a prompt, gets converted into a mathematical representation, lands in a retrieval index, gets processed by a model, generates an output, and leaves a trail of logs at every step. Each intermediate artifact carries your information. Some of it is more revealing than the original. The tension is simple. Vendors define Customer Data narrowly — the raw text you type and the final response you receive — and claim everything generated in between. Buyers want the whole pipeline: every derivative, every representation, every log that captures their content's statistical DNA. Three flashpoints dominate: derivatives (when your document becomes a high-dimensional vector, that vector is a compression of everything that made the text valuable — semantic relationships, domain terminology, confidential patterns; if the vendor owns derivatives, they own a machine-readable version of your trade secrets); retrieval indices (your knowledge base — searchable and operational; if the contract does not define it as Customer Data, the vendor keeps it after termination); and logs (every prompt, response, and latency metric maps your organization's strategic priorities; vendors classify logs as 'Usage Data' and claim broad rights). The fix: define Customer Data by function, not by artifact type. A non-exhaustive list handles what today's technology produces; the functional catch-all handles what tomorrow's produces. The standard vendor line — 'Customer Data means data, information, and content uploaded or provided by Customer to the Services' — creates a clean line: if you uploaded it, it's yours; if the system generated it, it's not. Everything valuable in an AI deployment sits on the wrong side of that line. The nine definitional terms that do work in every agreement: AI Feature / AI System (the umbrella trigger — every downstream obligation attaches here); AI Customer Input (prompts, documents, context, fine-tuning data — what the user types and what the system ingests on the customer's behalf); AI Customer Output (content, predictions, classifications, or recommendations the AI generates in response to Input); Data Derivatives (embeddings, inference logs, retrieval indices, fine-tuned weights, plus the functional catch-all); Usage Data (anonymous, aggregated metrics — the acceptable carve-out, but only where no specific customer can be identified); Aggregated Statistics (pooled across customers, anonymized — but 'aggregated' is often a training pipeline wearing a metrics label); Training Data (explicitly excludes Customer Data, AI Customer Input, AI Customer Output, and Data Derivatives); Provider AI Policies (the vendor's documented governance, referenced in the MSA to keep it current); and General-Purpose AI Model Provider (the third party behind the API — the flowdown target for every no-training promise). The negotiation sits in the 'hard middle': the vendor's position that embeddings are their technology because they built the embedding model and run the vector database. The buyer's counter: the embeddings encode the buyer's content, represent the buyer's knowledge base, and if the vendor can repurpose them after termination, the buyer's operational memory is being retained without consent. The resolution — where most enterprise deals land — is that derivatives are Customer Data, but the vendor is not required to export them in a usable format. The buyer gets a deletion obligation and a certificate; the vendor keeps the vector database architecture. --- ## Battleground 2: Reps, Warranties & AI Accountability URL: https://sarhandata.law/playbook/guide/ai-warranties-accountability Date: 2026-08-17 Category: Enterprise AI MSA Playbook The standard SaaS warranty says the service will 'conform to the documentation.' AI documentation says outputs may be inaccurate. A warranty of conformance to that documentation is a warranty of nothing. The buyer asks for a promise that the model will not cause harm. The vendor says nobody can promise that. The paper freezes. The breakthrough in the deals that close is shifting the warranty target from the output to the governance system that produces it. Buyers do not need a guarantee that every output is correct. They need a guarantee that the vendor runs a governance program designed to catch the worst failures before they reach the user. The standard vendor language — 'Provider warrants that the Services will perform materially in accordance with the Documentation. AI-generated outputs are provided AS-IS without warranty of any kind' — lets the vendor publish documentation that says 'outputs may be inaccurate' and call it a day. The buyer has no remedy for a model that produces harmful, biased, or fabricated results. The governance-anchored warranty changes the target. The buyer does not get a guarantee that every output is correct. The buyer gets a guarantee that the vendor maintains documented policies and procedures for bias monitoring and mitigation, hallucination testing and accuracy measurement, human review protocols for outputs in high-risk categories, and remediation procedures linked to defined severity levels. If the vendor's model produces a toxic output that causes harm, the buyer does not have to prove the model was defective — they prove the vendor failed to maintain the governance program it promised. Risk classification matters. Not every AI output carries the same consequence. A chatbot suggesting product colors carries near-zero risk. An AI flagging insurance claims for denial carries enormous risk. The MSA should define risk tiers: Low (chat suggestions, summarization of public docs — standard governance program and periodic testing); Medium (internal analytics, draft generation with human sign-off — monthly bias testing, human review for flagged outputs); High (decisions with legal, financial, or health impact — human-in-the-loop mandatory, explainability documentation, higher accuracy thresholds, quarterly audit reports). This tiered approach lets the vendor commit to real accountability without over-promising on low-stakes features. The negotiation script resolves as a compromise: the vendor warrants that documented governance practices exist and are maintained, provides a summary against a recognized framework (NIST AI RMF 1.0 or ISO/IEC 42001), and commits to periodic testing. The audit right is limited to documentation review — not technical testing. The warranty covers the program, not the outputs. The buyer gets a contractual hook for due diligence. The vendor avoids per-output liability. Both sides can tell their board the deal is documented, tested, and verifiable. Governance warranties are becoming standard in this market. Deals close fastest when the vendor drafts a governance warranty up front, leaving the negotiation focused on scope and audit mechanics — not whether a warranty should exist at all. --- ## Battleground 3: Risk Allocation URL: https://sarhandata.law/playbook/guide/ai-risk-allocation Date: 2026-08-17 Category: Enterprise AI MSA Playbook When an AI output infringes a third-party copyright, or when a hallucinated response causes financial loss, the law is still figuring out who owns that harm. The vendor's contract is the only architecture you have to fill the gap right now. Most vendor paper is designed to make sure the buyer carries the cost. Three levers determine the outcome: indemnification (who pays when a third party sues), liability caps (the maximum either party can lose), and carve-outs (which losses are not capped at all). In an AI deal, these determine whether the vendor is selling you a tool or a liability. Vendors typically open with a symmetrical structure: mutual IP indemnification, but only for the vendor's underlying platform — not for what the AI generates. Liability capped at 12 months of fees. No dollar floors. No separate cap for data breaches. The message: we will stand behind our code. What the AI does with your data is your problem. Buyers look at the same structure and see a risk chasm. The buyer did not train the model. The buyer cannot predict when it will hallucinate or reproduce training data. Yet under standard paper, the buyer indemnifies the vendor for output-related claims, and the vendor's total exposure is capped. For a $100K contract, that is a $100K cap on a risk that could generate millions in damages. The math does not work. The fix requires three components working together. First: output indemnification. The vendor carries the infringement risk for unmodified outputs used as intended. The carve-outs are narrow: input materials that are themselves the basis of the claim; the buyer's combination of output with non-Provider materials; uses the vendor warned against in writing. This flips the baseline — the vendor stands behind what its AI produces. Second: dollar floors. A pure fee-multiple cap is a trap in small deals. A $50K contract with a 1x cap means the vendor's maximum exposure for a data breach is $50,000 — immunity, not risk management. A $250,000 floor ensures the vendor has skin in the game regardless of contract size. Third: a super-cap for data breaches. Security incidents should not share the same cap as commercial liability. The 2x fee multiple with a $500K floor creates a separate risk architecture for the vendor's most consequential failure mode. The compromise that closes enterprise deals: the cap stays at 12-month fees, but a $250K floor applies to contracts below that threshold. Data breaches get a separate super-cap at 2x fees with a $500K floor. Output indemnification is available for unmodified outputs used as intended, with narrow carve-outs the vendor needs to avoid unbounded risk. Both sides carry proportionate exposure: the vendor carries the risk it controls (model selection, integration, marketing), the buyer carries the risk of downstream use. --- ## Battleground 4: SLAs: Model Availability, Output Quality & Token Latency URL: https://sarhandata.law/playbook/guide/ai-sla Date: 2026-08-17 Category: Enterprise AI MSA Playbook Most enterprise AI deals ship with an SLA written for a different product. The uptime commitment covers the login page, the API endpoint, the dashboard. It does not cover the model. The mechanism matters. Traditional SLAs measure whether the application responds to a ping. AI SLAs need to measure whether the model is available, whether the outputs are fit for purpose, and how long the user waits between prompt and response. The system can be up while the model is effectively down. A model endpoint returning a 200 OK but producing gibberish is 'available' under a standard uptime SLA. A model silently swapped for a cheaper version is 'available.' A model timing out on every third request because the inference provider is throttling is 'available.' Standard vendor language — '99.5% system availability measured monthly. Downtime caused by third-party providers is excluded' — covers the wrapper. The model, the inference provider, the entire AI pipeline: excluded. The enterprise counter creates two distinct tiers. System availability (99.5%, service credits as remedy) and model availability (99.0%, with a termination right as remedy for sustained failure). Model Unavailability is defined through objective, measurable criteria: the AI feature returns error responses for more than 5% of queries in a measurement window; the named model version specified in the Order Form is unavailable or has been replaced without notice; or the 95th-percentile response latency exceeds three times the baseline defined in the Order Form. Output quality remains the largest gap between what procurement wants and what the market offers. No vendor in the market commits to output accuracy. The resolution is shifting from accuracy warranties to accuracy monitoring: the vendor regularly measures AI feature accuracy against mutually agreed benchmarks, provides quarterly accuracy reports, and if accuracy falls below the defined threshold for two consecutive quarters, either remediates or permits the customer to terminate without penalty. The outcome-based pricing alternative is available for task-specific AI. The vendor charges per successfully completed task. No uptime commitments, no accuracy benchmarks, no credit structures. The buyer verifies resolution counts. If the system underperforms, the vendor earns less or nothing. This eliminates the two-tier SLA compromise and replaces it with a pricing structure that does not need one. It is the strongest approach available for task-specific AI. Provider-side outages require specific handling. When the inference provider goes down, the vendor's standard SLA excludes that downtime. The enterprise counter: the vendor warrants system availability excluding only outages caused by third-party providers where the vendor has no contractual right to prioritize or supplement capacity. This narrows the carve-out to genuinely uncontrollable failures. On model change notice: the vendor must provide at least 30 days' advance notice before a material change to the underlying AI model, giving the buyer a window to test before the change takes effect. --- ## Battleground 5: Security: ZDR, Sub-Processors & AI-Specific Controls URL: https://sarhandata.law/playbook/guide/ai-security Date: 2026-08-17 Category: Enterprise AI MSA Playbook Standard SaaS security frameworks assume the perimeter is the boundary. SOC 2 Type II and ISO 27001 cover infrastructure, access controls, and operational security. They do not cover whether the LLM provider retains prompts, whether your retrieval index is tenant-isolated, or whether model outputs can leak training data. Enterprise deals stall when the vendor's Security Addendum is silent on AI-specific attack vectors — prompt injection, model inversion, and data poisoning — and the buyer's security team refuses to sign off. An AI Security Schedule must address five components that traditional security frameworks do not reach. First: Zero Data Retention verification. The contract must require that all third-party AI providers operate under ZDR terms, backed by evidence — not a trust center link. The vendor must ensure model inference providers prohibit retention of Customer Data after inference completion, prohibit use of Customer Data for model training or improvement, and require deletion within 30 days of processing. Upon request, the vendor must provide written evidence including contractual excerpts or third-party audit reports. The trust center page is the floor. Contractual verification is the ceiling. Second: Sub-processor disclosure. The DPA sub-processor list must include AI providers and distinguish between infrastructure and model providers. The vendor must maintain a list of all sub-processors, including model inference providers and embedding service providers, and provide at least 14 days' prior notice before engaging a new model inference provider. A website update is not prior notice. The buyer needs a contractual right to object on reasonable data protection grounds — and an exit right if the objection cannot be resolved. Third: AI-specific controls. The Security Schedule must address prompt injection defenses, output monitoring, data leakage prevention, and adversarial testing. Many vendors prohibit customers from conducting vulnerability assessments on AI features. The enterprise counter requires the vendor to implement prompt injection and jailbreak defenses, monitor outputs for toxicity, bias, and data leakage, conduct annual adversarial testing, and permit the customer to conduct security assessments on 30 days' notice, subject to reasonable scope limitations. A vendor that refuses to disclose testing rights is a red flag. Fourth: Forensic investigation. Standard incident response covers unauthorized access. AI incidents are different: harmful outputs, training data leakage, and prompt manipulation do not require a traditional breach. In the event of an AI Security Incident — defined as any unauthorized access, manipulation, or unintended behavior resulting in disclosure, corruption, or misuse of Customer Data — the vendor must engage an independent forensic investigator at its expense and provide results within 30 days. Fifth: Governance framework alignment. NIST AI RMF 1.0 and ISO/IEC 42001 are voluntary, but the market is treating them as de facto diligence standards. The vendor must maintain an AI risk management program aligned with one of these frameworks and provide the customer with a summary of its most recent assessment upon request. If a vendor cannot articulate how their system maps to one of these frameworks, the deal stalls. --- ## Battleground 6: IP, Licensing & Feedback Loops URL: https://sarhandata.law/playbook/guide/ai-ip-licensing Date: 2026-08-17 Category: Enterprise AI MSA Playbook In a traditional SaaS deal, IP is a second-act negotiation. In an AI deal, it is the first thing that breaks. Output ownership, derivative data, and training prohibitions each require their own approach. The market has converged on output ownership: the customer owns what the AI generates. Most vendors assign their interest in outputs. That sounds clean. But LLMs are stateless and probabilistic — two customers can receive identical outputs from similar prompts. Ownership does not mean exclusivity. The standard vendor clause assigns output ownership but says nothing about whether the vendor retains any license back to use those outputs, and does not address the reality that identical outputs can reach multiple customers. The enterprise counter adds two critical elements: an explicit acknowledgment that outputs are not exclusive (reflecting how the technology works), and a limitation of the vendor's license back to service provision only. In one financial services negotiation, the deal nearly collapsed over a perpetual license-back clause buried in the vendor's output IP section — the vendor had offered clean output assignment but had also drafted an unbounded right to use all outputs for 'model improvement.' The fix: limit the license to the term of the agreement, exclude outputs used in production, and add a deletion obligation at termination. Training data provenance is the gap the market has not closed. The vendor indemnifies for output infringement, but no vendor warrants that their foundation model was trained on lawfully obtained data. This is the invisible layer of liability. A training data class action can reach the vendor's model behavior in ways no output indemnity covers. Enterprise buyers should ask for a representation that the vendor's model provider has obtained training data lawfully to the best of its knowledge. Most vendors will resist. The fallback: a commitment to notify the customer if the vendor becomes aware of a training data challenge, plus a right to terminate if the challenge materially impacts the service. The derivative data gap must be closed at the definition level (Chapter 5) and acknowledged in the IP section. If derivatives are not in the Customer Data definition, the vendor owns them by default. The IP section must confirm: 'For clarity, Customer retains all right, title, and interest in and to Customer Data as defined in Section [X], including all derivatives thereof.' The training prohibition has reached near-consensus — vendors will not train on customer data. The debate has shifted from whether to how verified. The vendor's no-training promise must flow down to every third-party AI provider in the supply chain. The standard vendor language — 'Provider will not use Customer Data to train, improve, or modify any models' — does not specify which models (the vendor's or the model provider's), does not flow down to the model provider, and the vendor may not control the provider's data practices at all. The enterprise counter requires the vendor to contractually bind every Third-Party AI Provider. The feedback trap is the most dangerous clause in a standard AI MSA: 'Customer grants Provider a perpetual, irrevocable, worldwide, royalty-free license to use any feedback, suggestions, or ideas provided by Customer regarding the Services.' This is a data capture mechanism. Your feature requests, usage patterns, and improvement ideas are owned by the vendor forever. In an AI context, this is a training data pipeline disguised as a collaboration clause. The fix: void the assignment, license feedback for the vendor's internal use only, and explicitly exclude Customer Data and Customer Confidential Information from the feedback license. --- ## Battleground 7: Termination & Exit URL: https://sarhandata.law/playbook/guide/ai-termination-exit Date: 2026-08-17 Category: Enterprise AI MSA Playbook In traditional SaaS, exit is about getting your raw data back. In AI SaaS, you are retrieving the operational memory of your business — data formats that did not exist when most MSA templates were drafted. Standard paper defines Customer Data as 'data uploaded by Customer.' Derivatives, generated by the service rather than uploaded by the customer, fall outside the return obligation. The vendor hands back your PDFs but not the retrieval index. You have the ingredients without the recipe. Switching costs become prohibitive. That lock-in is what the exit clause is supposed to prevent. The data return scope problem is foundational. Standard vendor language offers a 30-day export in the vendor's standard format. Two gaps: 'Customer Data' does not include derivatives, and 'standard format' usually means a CSV dump. The enterprise counter requires: a complete export of all Customer Data including all derivatives, structured indices, and logs in a platform-agnostic, machine-readable format; reasonable transition assistance at no additional cost for 90 days; and permanent deletion of all copies with a certificate of deletion within 30 days of export completion. This covers scope (derivatives included), format (platform-agnostic), timing (90 days with assistance), and deletion verification. Four AI-specific termination triggers go beyond the standard 30-day cure period for material breach. Model deprecation: the vendor swaps the underlying model, output quality degrades on your use case, the service is technically 'available' but the AI feature is unfit for purpose. Regulatory shift: a regulator rules that the model architecture violates local law — the vendor cannot cure that in 30 days. Safety incident: the AI generates harmful outputs — biased results, fabricated sources — requiring immediate pause, not a 30-day wait. Model provider terms change: the vendor's underlying model provider changes its API terms in a way that undermines the vendor's contractual commitments on zero data retention, training restrictions, or security obligations. The Substantial Modification trigger is the most frequently negotiated AI-specific termination right. The vendor must provide at least 30 days' notice before a material model change. If the change materially degrades the documented use case and the vendor cannot restore performance within 30 days, the buyer may terminate the affected Service Order without penalty. The 'documented use case in the Order Form' anchors the trigger — preventing vendor claims that any update is not a modification while protecting the buyer's actual workflow. Suspension rights require balancing. Vendors reserve broad suspension rights — for non-payment, suspected misuse, 'threats to the service.' Buyers need to narrow those rights and add mutual suspension for AI-specific safety or compliance risks. The compromise: vendor retains the right to suspend immediately for security reasons but must provide notice and the grounds; if suspension exceeds 30 days, the customer may terminate without penalty. The vendor's operational risk justifies unilateral security suspension; the termination backstop prevents indefinite suspension being used as leverage. --- ## Chapter 12: The Regulatory Overlay URL: https://sarhandata.law/playbook/guide/ai-regulatory-overlay Date: 2026-08-17 Category: Enterprise AI MSA Playbook Negotiating AI SaaS MSAs means negotiating against a moving regulatory target. Keeping up with regulatory trends ensures that the contracts you draft will be durable into the future. AI regulation globally operates along two independent axes. First, subject matter: what the law targets. Three species dominate — Frontier Model Safety (regulating the largest, most capable models at the development layer), Algorithmic Discrimination (protecting individuals from biased automated decisions in employment, housing, credit, and healthcare), and Transparency & Disclosure (requiring notice, explanation, and documentation when AI processes personal data or makes consequential decisions). Second, approach: Comprehensive Framework jurisdictions (a single integrated AI law covering multiple species — EU, Korea, Brazil, Canada's historical trajectory with AIDA) versus Soft Law/Innovation First jurisdictions (voluntary frameworks, sectoral rules, and regulatory sandboxes — Japan, Singapore, UAE, Saudi Arabia). The approach axis tells you how hard the obligation bites. A principles-based obligation under a sandbox regime is a different contractual animal than a prescriptive obligation under a comprehensive framework with €35M fines. Both axes matter for procurement: the subject-matter axis tells you which battlegrounds matter most under which regulator; the approach axis tells you how to calibrate the contractual response. In the US, no federal AI law exists. State pressure comes from three directions. Algorithmic discrimination: Colorado's AI Act (SB24-205, effective February 1, 2026) imposes a duty of reasonable care on developers and deployers of high-risk AI systems to protect consumers from algorithmic discrimination — with an affirmative defense for organizations aligned with NIST AI RMF or ISO 42001 (a direct incentive to anchor contracts to those frameworks). New York City's Local Law 144 requires bias audits for automated employment decision tools (enforcement active). Transparency and disclosure: California continues rulemaking on automated decision-making technology under the California Privacy Rights Act. Frontier model safety: California's frontier model safety efforts sit at the development layer and do not directly regulate enterprise deployers — but they affect your vendor's model provider obligations. Globally, the EU AI Act is the high-water benchmark. It entered into force August 1, 2024, with obligations phasing in through August 2026, and classifies systems by risk. High-risk systems trigger obligations for data governance, transparency, accuracy, robustness, and human oversight. Fines reach €35 million or 7% of global annual turnover. For any buyer whose vendor's AI system processes data in the EU or serves EU-based users, the EU AI Act's obligations are extraterritorial and immediate. Korea's AI Basic Act and Brazil's proposed AI framework follow the same structural pattern. Canadian buyers face three live pressures, none of which wait for federal AI legislation. PIPEDA enforcement: the Office of the Privacy Commissioner, alongside provincial counterparts in Quebec, British Columbia, and Alberta, has made clear that existing privacy law applies to AI processing. The OPC's joint investigation into large language model providers established: publicly accessible training data does not mean consent-free; user interfaces must enforce privacy by default; indefinite retention of personal information used in training is unacceptable. Quebec Law 25 is in force with administrative penalties and directly challenges AI systems that process data through third-party model inference providers — every sub-processor in the AI supply chain must be disclosed and flow-down terms must reflect Quebec's heightened standard. British Columbia PIPA and Alberta PIPA impose consent and breach-notification regimes, with BC's commissioner actively enforcing in AI-driven processing contexts. Canada's AIDA (Bill C-27) would have established a comprehensive framework with high-impact system classification, transparency obligations, and human oversight requirements. It died on the order paper when the 44th Parliament dissolved in January 2025 but remains the most detailed legislative signal of where Canadian federal law is heading. The regulatory change clause is the contractual answer: if a change in applicable law renders continued use of the AI Services unlawful, subject to regulatory pre-market authorization that the Provider cannot reasonably obtain, or commercially unreasonable due to new compliance costs, the customer may terminate without penalty. Both sides must be able to pause quickly when the regulatory environment shifts. --- ## Chapter 13: The AI-Native Redline Workflow URL: https://sarhandata.law/playbook/guide/ai-redline-workflow Date: 2026-08-17 Category: Enterprise AI MSA Playbook Most enterprise AI deals do not die in the last mile. They die in the first 72 hours. The deal stalls not because the positions are irreconcilable — but because the cadence is wrong and the triage is absent. Vendor sends paper. Procurement sends redlines. Both sides wait. Enterprise counsel marks up every clause. The vendor's counsel, often lean, sees a wall of red and does not know where to start. So nobody starts. Two weeks pass. Momentum evaporates. The champion inside the enterprise moves on. The AI-native redline workflow inverts that pattern. Rule 1: Triage First. Draft Second. Before touching a single clause, identify the three to five battlegrounds that move the needle. Training data. Output IP indemnity. Model change notice. Sub-processor flowdown. Everything else is noise for round one. Prepare a one-page issues list for business stakeholders — not a markup. The conversation surfaces real constraints on both sides. It takes 24 hours, not two weeks. The issues list identifies where each side has hard constraints (things they cannot move on) versus negotiating positions (things they are willing to trade). That distinction is invisible in a 47-clause markup. It is visible in a one-page email. Rule 2: Find the Line It Turned On. Every AI deal has one clause that, if resolved, makes the rest negotiable. Sometimes it is the training prohibition. Sometimes the dollar floor on the cap. Ask both sides: 'If we got this one point right, would you sign the rest as-is?' That question shifts the negotiation from positional bargaining to problem-solving. It also reveals which fallbacks to pre-position. Once both sides identify the line, the negotiation contracts from 47 issues to one — with the understanding that resolution unlocks everything else. Rule 3: Pre-Position Fallbacks. Map the vendor's standard fallback positions from market patterns — not from their paper, but from how deals with similar architecture actually resolve. When the buyer pushes for model accuracy warranties, you already know the vendor will counter with governance monitoring. Put that middle ground in your first draft, not your third. Cut two rounds out of the cycle. The Playbook's vendor position language in each battleground chapter documents those fallback positions — not hypothetical stances, but the postures the market has reached through repeated iteration. The cadence should be async-first. Five minutes covering the three changes that matter and why. Vendor's counsel reviews on their own time, responds with their own rationale. Done in a day. Live calls are for escalation, not default workflow. A video walkthrough of the three-issue markup takes five minutes to record and saves two rounds of emails. The parties can absorb the information on their own schedules, in their own time zones, and respond with considered positions rather than reactive ones. The 72-hour case study: A mid-market AI SaaS vendor had a deal worth mid-six figures. The buyer's procurement flagged sixteen issues across the MSA, DPA, and AI addendum. Day one: triaged sixteen issues to four that were deal-critical. Sent a one-page email explaining why those four mattered and what the vendor's likely fallback would be on each. Agreed on target outcomes by end of day. Day two: drafted a clean redline reflecting those four changes, with a screen recording. Buyer's counsel reviewed, sent back two small tweaks. Day three: signed MSA. The remaining twelve issues moved to a post-signing amendment. They did not need to block the deal. The AI-native redline workflow is about precision, not perfection. Treat the contract as a decision stack to be sequenced rather than a document to be perfected. The deals that close are not the ones with the most thorough markup. They are the ones where the right three clauses got resolved first. ---