What the emerging rules ask for, and what they do not settle

A caution before anything else

AI regulation is unsettled, it differs by jurisdiction and sector, and it is changing while you read this. Nothing here is legal advice, and anyone shipping something consequential needs a lawyer in the relevant country. What follows is the shape of the landscape, which is useful for deciding what to measure and what to keep.

The voluntary frameworks

NIST’s AI Risk Management Framework (United States, voluntary) organises work into four functions: Govern, Map, Measure, Manage. This entire course lives inside Measure, and the framework’s contribution is mostly a shared vocabulary for talking to people outside engineering.

ISO/IEC 42001 specifies a management system for AI and can be certified against, in the same way as the better-known information-security standard. It asks about process (do you have policies, roles, and a review cycle) rather than about whether your model is any good. ISO/IEC 23894 covers risk management guidance.

Neither tells you what accuracy is acceptable, because no standard can.

The EU AI Act, in outline

The Act sorts systems by risk. A small set of practices is prohibited outright. A defined list of high-risk uses (including employment, education, essential services, and certain safety components) carries substantive obligations: risk management, data governance, technical documentation, automatic logging, human oversight, and stated levels of accuracy, robustness and cybersecurity. A further tier carries transparency duties, such as telling people they are interacting with a machine or that content is synthetic. General-purpose model providers carry their own obligations.

The obligations are phased, the harmonised technical standards that operationalise them are still being produced, and national implementation and enforcement practice are still forming. Anybody who tells you exactly what a given clause will require of your product in practice is ahead of the evidence.

The rules that will bind you sooner

For most teams, sector-specific and existing law matters more than any AI-specific statute:

• Medical devices, where software that supports diagnosis has been regulated for years.
• Financial services model risk, with long-standing supervisory expectations about validation, independent review and documentation.
• Employment screening, where some jurisdictions already require bias audits of automated hiring tools.
• Data protection. In India the Digital Personal Data Protection Act governs personal data; in Europe the GDPR does, including rules about automated decisions. Both bear directly on whether user content may become an evaluation set.
• Consumer protection and advertising law, which is where “our AI is 99% accurate” becomes a claim you must be able to evidence.

What they all converge on

Read across the frameworks and the same practical list appears every time. If you do these, you are most of the way to any of them:

1. Documented intended use and out-of-scope use.
2. Documented data provenance, including consent basis and dates.
3. Measured performance, reported per relevant group rather than only in aggregate.
4. Logging sufficient to reconstruct a decision after the fact.
5. Human oversight that is specified and, ideally, measured.
6. Incident response, including a way for affected people to complain and be answered.
7. Periodic re-evaluation, with results retained.

Point seven has a practical consequence that surprises teams: you may need to answer “how did you know it worked” about a version you shipped eighteen months ago. That means retaining evaluation artefacts (the set as it was, the results, the model version, the report) not just the current ones. Storage is cheap; reconstructing a defence is not.

What this changes about how you measure

Three things in this course become obligations rather than good practice once any of these regimes applies to you.

Per-group reporting stops being optional. An aggregate figure does not answer a question about whether a system works for a protected group, and the fairness arithmetic later in this course is the technical content behind that requirement.

Accuracy claims must be evidenced. Whatever level you state in your documentation is a level somebody may hold you to, which argues for stating a measured figure with its interval and its set, rather than a round number that sounded good.

Logging becomes a design constraint. “Sufficient to reconstruct a decision” is a demanding specification, and it is much cheaper to build at the start than to retrofit after a request arrives.

The honest limit

Compliance is not safety. A system can satisfy every documentation requirement and still hurt people, and a careful system can be non-conformant on paperwork. The frameworks are floors and record-keeping disciplines, and they are worth meeting; they are not a substitute for the measurement judgement this course has been about, and treating them as one is how organisations end up with excellent binders and unexamined systems.