The rules, where they agree and where they do not

What this lesson is not

It is not legal advice, and it cannot be. The law here differs by country, is being written while you read this, and is contested in courts that have not finished. Anyone who tells you the position is settled is selling something. What follows is the shape of the argument, so you know which questions to take to somebody qualified.

Where things are broadly converging

Across quite different legal systems, four themes recur.

Transparency when a system interacts with people. Some form of duty to say that an interaction is automated.

Records for consequential uses. Where a system contributes to decisions about credit, employment, education, benefits, insurance or policing, expectations of logging, documentation and traceability rise sharply.

Human oversight. Not a person present at every step, but a person able to intervene, override and be accountable.

Existing law applies anyway. Data protection law covers personal data whether a model touched it or not. Sector regulators (financial conduct, medical devices, employment discrimination) apply their existing rules to systems that use models, often without needing anything new. This is the point most teams underestimate: the majority of the rules that bind you predate the technology.

Where they diverge sharply

What counts as high risk. The EU AI Act sets tiers with obligations phasing in over several years. Other jurisdictions use sectoral rules, or state and provincial laws, or guidance rather than statute. The same product can be tightly regulated in one market and largely unregulated next door.

Automated decisions with legal effect. European data protection law gives people rights around decisions made solely by automated means, including a route to human intervention. Other regimes address this narrowly, sectorally, or not at all.

Training data and copyright. Genuinely unresolved. Some jurisdictions have text-and-data-mining exceptions with conditions and opt-outs; others have nothing comparable. Whether training on copyrighted works is permitted, whether outputs can infringe, and who owns model output are live questions with cases pending and decisions that have gone in different directions. Nothing in this course resolves it, and any confident answer you read, in either direction, is an opinion wearing a fact’s clothing.

Data localisation and cross-border transfer. India’s DPDP Act, various sectoral rules and several national frameworks constrain where data may be processed. This changes which providers and which regions you may use, and it is a design constraint rather than a paperwork one.

The four things to build regardless

This is the useful part, because it transfers.

1. Records of what the system did. Input reference, decision, config version, timestamp, whether a person reviewed it. Retained for a stated period.
2. A human who can override, named, with the authority and the interface to do it, and evidence that overrides actually happen, because a review mechanism nobody has ever used is not oversight.
3. An explanation of the basis, in the affected person’s terms: what information was used and what rule applied.
4. A deletion path that reaches every copy, tested.

Build those and you have the substance of most regimes’ requirements, and a defensible position in the ones you have not read yet. Skip them and no amount of policy documentation compensates.

The rule that is not controversial anywhere

If a decision materially affects somebody’s life (money, employment, housing, health, education) a person must be able to review it, and you must be able to say what it was based on.

Almost no regulator, in any jurisdiction, disagrees with that. It is also cheap to build if you build it from the start and expensive to retrofit, because retrofitting means finding out that you never logged the inputs.

How to work with the uncertainty

Do not wait for clarity; it is not arriving soon. Do not pretend to certainty you do not have, in either direction: “it’s all illegal” and “there are no rules” are both wrong and both lead to bad decisions.

Practically: write down what your system does in plain language, one page. Take that page to a lawyer in each market you operate in, and ask specific questions rather than general ones. Record what you were told and the date, because the answer will change and you will want to know which version you built to. And keep a note of anything you chose not to do because the position was unclear: that record is worth a great deal if anyone ever asks how you approached it.