Downstream use restrictions: surveillance, weapons and other prohibited uses

What a prohibited uses clause actually controls#

A prohibited uses clause controls what the licensee may not do with licensed data, whatever the grant otherwise allows. It sits beside the permitted use grant, which remains the main control: a narrow grant already excludes most unwanted uses, and the prohibited list removes doubt about the ones that matter most to the supplier.

The clause can reach three layers: the licensed records themselves, datasets derived from them, and models trained on them. The further down that chain a restriction reaches, the harder it is for the licensee to accept and for the supplier to verify.

Uses suppliers commonly restrict#

Suppliers commonly restrict a short list of uses that carry legal, reputational or commercial risk for them in particular. Not every restriction suits every deal, so treat the table as a menu of candidates, each with the reason it tends to appear.

Why restrictions on general-purpose models are hard to police#

Restrictions on general-purpose models are hard to police because the licensee does not control every downstream use. A model trained on many sources, including your records, may be offered to many customers for many tasks, and no data supplier can see those uses.

Practical clauses separate the layers. Strict restrictions apply to the licensee's direct handling of the data and to specialized models built mainly from it. For general-purpose models, the supplier relies on the licensee's own usage policies for its customers, with a covenant that those policies keep prohibiting the uses the supplier cares about most.

Responsible AI licenses, often called RAIL licenses, take a similar approach for released models by attaching use restrictions that pass to each user. Data suppliers can borrow that pattern through flow-down terms.

How to make a restriction checkable#

A restriction is checkable when both sides can tell, from documents the licensee already produces, whether it is being met. Vague restrictions fail that test and tend to be negotiated away or quietly ignored.

The test to apply while drafting is simple: for each restriction, could someone at the licensee point to a policy, record or control that shows compliance? If not, narrow the wording until they could. Attestations and audits then confirm the answer rather than replace it.

• 1Define each restricted use by the activity, not the intention: building or selling a product that locates identified individuals, rather than surveillance.
• 2State which layers it covers: the records, derived datasets, specialized models built mainly from the data, or all three.
• 3Name the evidence for each restriction, such as the licensee's customer usage policy for tracking limits or its internal data catalog entry for resale limits.
• 4Require written flow-down to affiliates, contractors and permitted sublicensees, plus a list of who received the data.
• 5Require prompt notice if the licensee learns of a breach, with a cure period only where a cure is actually possible.
• 6Link a material breach to termination and to deletion of the data and derived datasets.
• 7Fold use restrictions into the same periodic attestation that covers deletion instead of creating a separate report.

Weak wording and checkable alternatives#

Weak wording usually sounds principled but leaves no test for compliance. The checkable alternatives below are narrower, which also makes them easier for a licensee's counsel to approve.

Which red lines matter most for your records?#

The red lines that matter most are the ones your own records could realistically enable. A restriction that guards against a plausible misuse of your data is worth negotiating hard; a restriction copied from another deal may cost goodwill without reducing any real risk.

• 1Home services and field service records: homeowner addresses, gate codes and technician locations point to tracking and re-identification restrictions.
• 2Software support and engineering records: roadmaps, pricing and customer names point to competitive use and re-identification restrictions.
• 3Staffing and recruiting records: candidate histories point to bans on eligibility decisions about individuals.
• 4Logistics records: shipper volumes and lanes point to resale and competitive use restrictions.
• 5Consulting and engineering firm records: client material points to redistribution and confidentiality restrictions.

Illustrative: a field service company sets its red lines#

Illustrative: a fictional commercial HVAC service company plans to license dispatch records, technician notes and service outcomes from its FieldEdge system. Its archive also includes vehicle telematics from Samsara showing where each technician was throughout the day.

The CEO's concern is that the records could help someone build tools to monitor workers or track individuals. The company excludes raw GPS data, keeps only job-level arrival and completion times, and sets its red lines: no use to build employee monitoring or individual tracking products, no re-identification of technicians or customers, and no resale of the records.

The buyer rejects an early draft that banned any harmful use, but accepts the enumerated list with flow-down to contractors, a periodic officer attestation and a termination right. A weapons restriction is added as a standard term.

How SourceX handles use restrictions#

SourceX raises permitted and prohibited uses at Rights, the second stage of the SourceX five-step transaction, and the supplier confirms them at Approval before any contract is signed. The agreed restrictions are recorded under permitted use in the SourceX Evidence Packet, so the buyer's reviewers and the supplier work from the same list.

What SourceX may do with a deidentified dataset is defined in the signed agreement, and the supplier keeps ownership of its records throughout, which keeps termination and deletion rights meaningful if a restriction is breached.