Comparative Contract Drafting for Privacy and AI: Navigating Shall vs Must in Data Contracts

1) Grounding: US–UK conventions and obligation types in privacy/AI data contracts

In modern data-contract drafting, especially for privacy and AI clauses, the small word that marks obligation—shall or must—shapes both clarity and enforceability. In the United States, contemporary style guides and many in-house templates encourage using must for obligations because it is direct, unambiguous, and avoids the historical confusion of shall. By contrast, in the United Kingdom, shall still appears frequently in commercial forms. It is accepted when used carefully and consistently to mark binding obligations. This cross-border divergence matters because privacy and AI provisions often operate across jurisdictions, and misaligned modal verbs can change how counterparties understand risk, commitments, and remedies.

Despite stylistic differences, the core drafting principle is the same: use a modal verb only to create a real, enforceable obligation or to clearly signal permission or prohibition. The legal effect arises when the sentence identifies a responsible actor, uses a clear modal verb, and describes a precise action with a defined object, and any relevant condition. If shall or must appears where there is no duty (for example, merely predicting the future or describing a process), enforceability weakens because the text becomes ambiguous. In privacy and AI contracts, ambiguity can undermine regulatory compliance, incident response, audit rights, or data-sharing limitations.

Obligations in data contracts typically fall into four functional types that recur throughout privacy and AI terms:

• Mandatory obligations: required actions such as implementing security measures, giving breach notices, or completing Data Protection Impact Assessments (DPIAs). These call for must (US) or shall (UK, if house style accepts shall for duties) to signal a binding duty.
• Prohibitions: barred actions such as re-identifying anonymized data, using personal data for automated decisions without a legal basis, or transferring data to unapproved subprocessors. In US-oriented drafting, use must not or may not, while UK-leaning templates often use shall not if that is standard in the form. Avoid is not permitted unless it is a defined term with clear remedial consequences.
• Conditional obligations: duties that arise under conditions, such as conducting a DPIA before deploying a high-risk AI feature, or updating security controls upon a material change. These need precise triggers and consistent modals.
• Discretionary permissions: actions a party may take, such as using de-identified data for internal analytics under safeguards. Use may to indicate permission; avoid shall for permissions because it blurs duty with discretion.

Privacy and AI clauses intersect with frameworks like GDPR, CCPA/CPRA, state privacy statutes, and AI governance principles. Because these frameworks establish defined duties, the modal choice must align with the legal requirement and the contract’s risk profile. A misstep (for example, using shall to state a forecast rather than a duty) can cause interpretation disputes and compliance gaps.

2) Precision in obligation drafting: structure, effort standards, and common pitfalls

To write enforceable obligations, adopt a consistent clause structure: actor + modal + action + object + condition. Each element must be concrete:

• Actor: Name the specific party (Controller, Processor, Vendor) or its role (Data Importer, Subprocessor) without ambiguity. Avoid vague collective subjects like “the parties” unless the obligation truly applies to both simultaneously.
• Modal: Use must (US) or shall (UK) only when creating a binding duty. Use must not/shall not for prohibitions, and may for permissions. Reserve will for statements of future fact or logistics (timing, sequencing) when no duty is intended.
• Action: Use a measurable verb (implement, notify, restrict, delete, encrypt, document, assess) rather than abstract phrasing. Avoid nouns-as-verbs (“the deletion of data shall…”) because they obscure agency.
• Object: Define the scope—personal data categories, datasets, AI models, logs, outputs, or specific security controls—using terms that are either plain-language or defined in the definitions section.
• Condition: Tie duties to clear triggers (upon discovery of a Security Incident, prior to engaging a Subprocessor, if data falls within special categories), and specify timing standards (within X days) where needed to ensure enforceability.

In privacy and AI, obligations often incorporate effort standards and materiality qualifiers, which calibrate risk. An effort standard tells how hard the actor must try; a materiality qualifier sets the sensitivity threshold for consequences. They must align with the modal verb to avoid over- or under-commitment.

• Effort standards: “best efforts,” “reasonable efforts,” and “commercially reasonable efforts” signal different intensities. In highly regulated contexts (e.g., breach notification), use of an effort standard can be inappropriate if the law imposes strict requirements. Where flexibility is needed (e.g., evolving security controls), commercially reasonable efforts can balance practicality with diligence. Avoid stacking efforts (e.g., best and commercially reasonable) or mixing efforts with absolute requirements in the same clause.
• Materiality qualifiers: Words like material, material impact, materially adversely affect, or material change modify the duty or trigger. They must be defined or supported by context. For example, “material security incident” requires either a definition or cross-reference to applicable law; otherwise, parties may disagree about thresholds for notice or remediation.

Common pitfalls erode precision and enforceability:

• Futurity shall: Using shall to describe what will happen rather than to impose a duty (e.g., “The system shall be upgraded next year”) risks treating the sentence as prediction rather than obligation. Replace with must if mandating, or will if describing a plan.
• Vague subjects: Obligations imposed on undefined actors (“It shall be ensured that…”) hide responsibility and hinder enforcement. Name the responsible party.
• Over-broad conditions: Phrases like subject to applicable law or subject to internal policies can silently subordinate the core duty and create compliance escape hatches. Narrow the condition and place the exception after the duty, with specificity.
• Stacked exceptions: Long chains of subject to, except that, provided that, without limiting, and notwithstanding clauses make the obligation difficult to parse and may invert priority unintentionally. Use a priority-of-terms clause and organize exceptions logically.
• Muddled prohibitions: Avoid is not permitted unless it is a defined, enforceable term. Prefer must not (US) or shall not (UK) for clarity, consistent with house style. Ensure the prohibited behavior is specific and testable.

Precision also means synchronizing the modal with concrete measurements: deadlines, security control baselines, audit schedules, DPIA triggers, and notification pathways. Measurability helps both compliance and dispute resolution.

3) Translation and harmonization across US- and UK-leaning styles

In cross-border deals, you must convert clauses between US-leaning (must) and UK-leaning (shall) styles without changing risk. Harmonization relies on four practices: defining scope, mapping modal choices to risk posture, maintaining parallel structure, and preventing subject to cascades.

• Define scope first: Establish clear definitions for Personal Data, Confidential Information, Security Incident, Subprocessor, AI Output, Training Data, De-identified Data, and High-Risk Processing. Clear definitions let you swap modals without reinterpreting the obligation’s content.
• Map modals to risk: For duties that must be strictly met (e.g., legal breach notifications, honoring data subject rights), US style leans on must; UK style can use shall where house style accepts it for binding duties. For prohibitions, US style favors must not or may not; UK style may use shall not. For permissions, use may consistently in both.
• Maintain parallel structure: When converting, keep the actor-action-object-condition order. This preserves clarity and avoids accidental scope changes. If the US clause reads, “Processor must implement X,” the UK version should read, “Processor shall implement X,” not “It shall be implemented by Processor,” which obscures the actor and weakens enforceability.
• Prevent subject to cascades: Whether using must or shall, place exceptions precisely and avoid compounding. Prefer one clear exception per sentence, or use list structure. A priority-of-documents clause can handle conflicts without embedding endless caveats into each duty.

Special treatment applies to prohibitions, permissions, and conditionality:

• Prohibitions: Align with house style. In US forms, must not and may not are clearer than shall not. In UK forms, shall not is often standard, but only use it for true prohibitions. Ensure the negative is placed close to the verb to avoid misreading.
• Permissions: Use may. Do not use shall to signal permission; it reads as duty. Include any conditions for permission (e.g., security controls, anonymization standards) directly after the permission to avoid ambiguity.
• Conditionality: For DPIAs, data-sharing approvals, onshore data processing, and AI-use restrictions, specify conditions with clear triggers: before processing, upon identification of risk, upon regulator request. Ensure timelines are explicit and that the modal matches the required certainty.

For AI-related clauses, misused modals can unintentionally grant license or impose strict liability. For example, obligations on bias testing, explainability documentation, or restrictions on training data must be calibrated. Use must (US) or shall (UK) for non-negotiable compliance actions; use may only where discretion is intended and risk-assessed. Where uncertainty exists due to evolving standards, couple the duty with a defined effort standard and a reference to authoritative frameworks (without importing vague obligations by reference).

In security and incident response, timing is critical. Phrases like without undue delay can be compatible with must/shall, but pairing them with measurable outer limits (e.g., within 72 hours where legally required) prevents disputes. Harmonization means mirroring those timing terms across versions while adjusting only the modal verb to fit style.

Finally, recognize that many organizations adopt hybrid styles. A UK-drafted contract may still prefer must for some technical obligations (e.g., encryption) while retaining shall for general duties. If a house style is mixed, document the rule set in drafting notes and keep it consistent across all data and AI clauses to avoid interpretive drift.

4) Guided practice mindset: translation drills and a live-drafting checklist

Approach translation between styles as a controlled operation: you are not rewriting risk; you are re-encoding the same duty in a different dialect of legal English. The mental model is alignment, not creativity. Keep the actor-action-object-condition backbone constant, swap the modals per house style, and verify that effort standards and materiality qualifiers remain calibrated.

Use a checklist to maintain discipline during live drafting and redlining:

• Scope and definitions:

  • Are key data and AI terms defined with sufficient precision? Do cross-references point to authoritative sources or internal appendices?
  • Are data categories and processing purposes enumerated clearly so that modals attach to known objects?

• Modal selection and consistency:

  • For each sentence, is the modal verb aligned with the intended function: duty (must/shall), prohibition (must not/shall not or may not), permission (may), or future fact (will)?
  • Is the same modal used for the same function throughout the document to avoid interpretive inconsistencies?

• Clause structure:

  • Does each obligation name a responsible actor explicitly? Avoid passive voice that hides agency.
  • Does the action verb reflect a measurable behavior? Are deadlines and performance standards specified?

• Effort standards and materiality:

  • Where flexibility is necessary, is the chosen effort standard appropriate to the risk and regulatory environment?
  • Are materiality qualifiers defined or bounded to avoid disputes about thresholds for notice, remediation, or termination?

• Conditions and exceptions:

  • Are conditions truly necessary and carefully placed after the core duty? Avoid front-loading with subject to where it can obscure the primary obligation.
  • Is there a single, clear exception per sentence? If multiple are required, break into subclauses and preserve priority.

• Prohibitions and permissions:

  • Are prohibitions expressed with must not/shall not or may not, consistent with house style, and anchored to specific behaviors (re-identification, profiling, training use, cross-border transfer)?
  • Are permissions expressed only with may, with any prerequisites (e.g., de-identification thresholds, security safeguards) directly attached?

• Cross-jurisdiction harmonization:

  • When converting between US and UK styles, have only the modals changed, leaving actor, action, object, and condition intact?
  • Are regulator-driven timelines and obligations preserved exactly, with terms like without undue delay supplemented by concrete outer limits where applicable?

• Avoidance of ambiguity:

  • Have you eliminated futurity shall and replaced it with must or will as appropriate?
  • Are stacked exceptions and double negatives removed or simplified?

• Remedial clarity:

  • Do breach and consequence provisions map cleanly to the obligations created by the modals (e.g., termination rights, indemnities, specific performance)?
  • Are audit, verification, and cooperation obligations framed with modals that allow enforceable oversight?

Keeping this discipline ensures that your data privacy and AI clauses are not only stylistically coherent but also substantively enforceable across jurisdictions. The small words—shall and must—carry large consequences. Choose them with intent, tie them to identifiable actors and measurable actions, and calibrate them with effort and materiality only where appropriate. With this focus, your drafting will align legal risk with operational reality, making your contracts more reliable instruments for compliance, governance, and trust in the complex, fast-evolving domains of data privacy and AI.