Learn AI Create the Future — with Pranay
Main site

AI Safety and Ethics

AI regulation

Most AI rules share one shape — risk tiers, documentation, human oversight and an appeal route — so build the evidence and check the current text for specifics.

Read these first

On this page 8
  1. The short answer
  2. The analogy you have already lived
  3. The tiers you will meet
  4. What high risk actually asks for
  5. Where you have already felt this
  6. What is honestly hard here
  7. Remember this
  8. What to learn next

One lesson, three depths. Pick the one that fits you today — you can switch any time.

Beginner — No maths. Plain English.

The short answer

AI rules mostly do one thing: the more a system can hurt someone, the more you must prove about it before you ship.

The analogy you have already lived

Think about vehicles on a road. A bicycle needs nothing. A scooter needs a licence and a helmet. A school bus needs a fitness certificate, a trained driver, inspections and a logbook.

Nobody argues the bus rules should apply to the bicycle. The rules scale with what happens when things go wrong.

Almost every AI law in the world is built on this idea. It is called a risk-based approach, and once you see it, the different laws start to look similar.

The tiers you will meet

Different countries use different words. The ladder is roughly the same everywhere.

Not allowed. A short list of uses considered unacceptable. Social scoring by governments and some kinds of mass biometric surveillance appear on such lists.

High risk. Systems that decide access to something important — a job, a loan, a school place, a medical treatment, a public service. These carry the real paperwork.

Needs a label. Systems people interact with, or that generate content. The duty here is honesty: tell people they are talking to a machine, and mark synthetic media.

Everything else. Spam filters, recommendations, autocomplete. Ordinary product rules apply and little else.

Your first job is working out which rung your system stands on. Most engineering teams get this wrong by guessing low.

What high risk actually asks for

Strip away the legal language and the requirements repeat across jurisdictions.

Write down what it is for. And what it must not be used for.

Show it works, for everyone. Performance broken down by the groups affected, not one average number.

Say where your data came from. Provenance, licensing, and what is in it.

Keep a human in the loop. A person who can review, override and be accountable.

Give people a way to complain. An affected person must be able to ask why and contest it.

Keep logs. So that after an incident, somebody can reconstruct what happened.

Notice something. That is the same list as good engineering practice. The regulation is mostly asking you to write down what a careful team already does.

Where you have already felt this

  • Cookie banners and privacy notices came from data-protection rules.
  • Bank rejection letters that state a reason exist because of credit rules that predate AI.
  • "This chat is with an automated assistant" notices are a transparency duty.
  • Labels on AI-generated images are becoming standard for the same reason.

What is honestly hard here

The rules are new, they differ between countries, and they are still being interpreted. Two careful lawyers can disagree about whether a given product is high risk.

Timelines shift. Guidance arrives after the law. Something written today may be out of date by the time you read it, and that includes this page.

So do not try to memorise the law. Build the evidence a careful engineer would build anyway, and it will fit most rule sets with adjustments rather than a rewrite.

Remember this

  • Rules scale with harm: more risk, more proof required.
  • The recurring asks are documentation, group-level testing, human oversight and appeals.
  • Details change by country and over time — check the current text, and take advice.

What to learn next

Developer — Code and libraries.

Compliance is an artefact problem

You cannot code your way to compliance. What you can do is make the evidence a build output, so that a release either has it or fails.

The list below is not any single law. It is the intersection of what several frameworks ask for, expressed as files.

Setup

bash
python3 --version

Standard library only.

A release gate you can put in CI

release_evidence.py
import json, os, tempfile

# Evidence that most AI rules ask for, in one form or another. The wording differs
# between jurisdictions; the underlying artefacts are close to identical.
REQUIRED = {
    "model_card.md":        "what it is for, and what it is not for",
    "eval_disaggregated.json": "performance broken down by affected group",
    "data_provenance.json": "where the training data came from, and the licence",
    "risk_assessment.md":   "identified hazards, severity, and mitigations",
    "human_oversight.md":   "who reviews decisions, and how a person appeals",
    "logging_policy.md":    "what is logged, for how long, and who can read it",
    "incident_plan.md":     "how the system is switched off, and who decides",
}

release = tempfile.mkdtemp(prefix="release_v3_")
# a realistic half-finished release: some evidence exists, some does not
for name in ["model_card.md", "data_provenance.json", "logging_policy.md"]:
    open(os.path.join(release, name), "w").write("placeholder\n")
json.dump({"slices": {"all": {"n": 900, "recall": 0.865},
                      "device=old": {"n": 306, "recall": 0.808}}},
          open(os.path.join(release, "eval_disaggregated.json"), "w"))

print("RELEASE EVIDENCE CHECK")
missing = []
for name, why in REQUIRED.items():
    path = os.path.join(release, name)
    ok = os.path.exists(path) and os.path.getsize(path) > 0
    print(f"  [{'x' if ok else ' '}] {name:26s} {why}")
    if not ok:
        missing.append(name)

print(f"\n{len(REQUIRED) - len(missing)}/{len(REQUIRED)} artefacts present.")
if missing:
    print("BLOCKED. Missing: " + ", ".join(missing))

# A risk tier decides how much of the above is legally required, not only advisable.
def tier(uses_biometrics, affects_access_to, is_public_facing):
    if uses_biometrics and is_public_facing:
        return "likely prohibited or highest scrutiny"
    if affects_access_to in {"employment", "credit", "education", "housing",
                             "healthcare", "public services"}:
        return "high risk"
    if is_public_facing:
        return "transparency obligations (tell people it is AI)"
    return "minimal risk"

print("\nSELF-ASSESSED RISK TIER  (a triage aid, NOT a legal determination)")
for case in [
    dict(uses_biometrics=False, affects_access_to="employment",  is_public_facing=True),
    dict(uses_biometrics=False, affects_access_to="marketing",   is_public_facing=True),
    dict(uses_biometrics=False, affects_access_to="internal",    is_public_facing=False),
]:
    print(f"  {str(case):78s} -> {tier(**case)}")
Output
RELEASE EVIDENCE CHECK
  [x] model_card.md              what it is for, and what it is not for
  [x] eval_disaggregated.json    performance broken down by affected group
  [x] data_provenance.json       where the training data came from, and the licence
  [ ] risk_assessment.md         identified hazards, severity, and mitigations
  [ ] human_oversight.md         who reviews decisions, and how a person appeals
  [x] logging_policy.md          what is logged, for how long, and who can read it
  [ ] incident_plan.md           how the system is switched off, and who decides

4/7 artefacts present.
BLOCKED. Missing: risk_assessment.md, human_oversight.md, incident_plan.md

SELF-ASSESSED RISK TIER  (a triage aid, NOT a legal determination)
  {'uses_biometrics': False, 'affects_access_to': 'employment', 'is_public_facing': True} -> high risk
  {'uses_biometrics': False, 'affects_access_to': 'marketing', 'is_public_facing': True} -> transparency obligations (tell people it is AI)
  {'uses_biometrics': False, 'affects_access_to': 'internal', 'is_public_facing': False} -> minimal risk

Two things to take from that

The three missing files are the three nobody writes. Model cards and eval reports get produced because engineers enjoy producing them. Risk assessment, human oversight and the incident plan are organisational, so they get deferred until an auditor asks. Putting them in the same gate is the cheapest fix available.

tier() is a triage aid and nothing more. It sorts a product backlog so the right conversation happens early. It is not a legal determination, cannot be one, and a comment saying so belongs in the code.

What the artefacts should actually contain

data_provenance.json — per source: origin, licence, collection date, whether personal data is present, and whether the licence permits your use. Copyright and licensing of training data is genuinely unsettled law in several jurisdictions. Record what you used; you cannot reconstruct it later.

risk_assessment.md — hazards, each with likelihood, severity, who is harmed, and mitigation. The structure from why AI safety matters fits directly.

human_oversight.md — the named role that reviews, the volume they can realistically handle, what authority they have to override, and how a person outside the company raises a complaint. "A human reviews everything" is not credible at 10,000 decisions a day; say what is actually sampled.

incident_plan.md — the kill switch, who may pull it, the rollback procedure, and the notification path. Covered in deploying responsibly.

Common mistakes

Assuming the rules apply only where your servers are. Several regimes attach to where the affected person is, not where the company sits. An Indian startup serving European users is inside the European perimeter.

Assuming an open-source model shifts responsibility. In most framings the party deploying the system to affected people carries the deployment duties, whoever trained the weights.

Treating a vendor's compliance claim as yours. Ask what the vendor certified, for which use, and get the documentation you would need to answer a regulator's question yourself.

Logging everything forever to be safe. That collides directly with data-protection rules. Define retention deliberately: long enough to investigate an incident, short enough to be defensible.

Waiting for perfect clarity before starting. The artefacts above are useful regardless of how the law settles. Building them now is the low-risk move in either direction.

Try it yourself

Run this against a real release directory in your own repo. Count how many of the seven exist. Then add the check to CI as a warning rather than a failure for one sprint, and see whether the count moves on its own.

What to learn next

Researcher — Mathematics and papers.

The regulatory landscape, as a shape rather than a list

Four architectural patterns recur, and knowing which one a jurisdiction uses predicts most of its details.

Risk-tiered product regulation. The EU AI Act is the clearest example: prohibited practices, high-risk systems with conformity requirements, transparency obligations for certain systems, and minimal-risk everything else, with a separate track for general-purpose AI models. It borrows its structure from EU product-safety law, which explains its vocabulary — conformity assessment, CE marking, notified bodies, post-market monitoring. The Act entered into force in 2024 with obligations phasing in over subsequent periods; the phase-in dates have been subject to amendment and should be read from the current consolidated text rather than from secondary sources.

Sectoral enforcement under existing law. The United States has no comprehensive federal AI statute. Instead, existing authorities are applied: the FTC Act against unfair or deceptive practices, the Equal Credit Opportunity Act and Regulation B requiring specific adverse-action reasons for credit denials, the Fair Credit Reporting Act, Title VII for employment, and FDA pathways for medical devices. The practical consequence: an adverse-action requirement to state actual reasons predates AI by decades and constrains model choice in credit today.

Data-protection law as de facto AI law. GDPR Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects, with Articles 13 to 15 requiring meaningful information about the logic involved. The extent of any "right to explanation" is genuinely contested in the literature — see Wachter, Mittelstadt and Floridi (2017) arguing against a legally binding right, and Selbst and Powles (2017) arguing for a substantive reading. India's Digital Personal Data Protection Act, 2023 is a consent-and-purpose regime without AI-specific automated-decision provisions; sector regulators have issued their own guidance.

Subnational and sector-specific rules. New York City Local Law 144 requires an independent bias audit for automated employment decision tools with published summary results. Colorado enacted an algorithmic discrimination statute in 2024 with a duty of reasonable care for developers and deployers of high-risk systems; its effective date has been amended. Illinois BIPA governs biometric identifiers with a private right of action, and has produced the largest damages in this area. China regulates by application type: algorithmic recommendation provisions (2022), deep synthesis provisions (2023), and interim measures for generative AI services (2023), with filing requirements for public-facing services.

Canada's proposed AIDA within Bill C-27 did not pass before Parliament was prorogued; treat it as a signal of direction rather than as law.

Voluntary frameworks that carry practical weight

  • NIST AI Risk Management Framework 1.0 (2023) — Govern, Map, Measure, Manage. Voluntary, and increasingly referenced in procurement and in guidance as a benchmark of reasonable practice.
  • ISO/IEC 42001 (2023) — an AI management system standard, certifiable, structured like ISO 27001. Useful where a customer requires an auditable certificate.
  • ISO/IEC 23894 (2023) — AI risk management guidance.

Harmonised technical standards matter more than they appear. Under EU product-safety architecture, conformity with a harmonised standard grants a presumption of conformity with the legal requirement. The standards work at CEN-CENELEC therefore determines much of what compliance concretely means, and it proceeds on its own timeline.

Open technical questions the law has created

What counts as an explanation. Legal requirements to state reasons interact badly with post-hoc attribution methods that are approximations with unreported error, and that can be adversarially manipulated (Slack et al., 2020). Counterfactual explanations (Wachter et al., 2017) are better matched to the legal form, and are gameable by design.

How to audit without access. Raji et al. (2020) describe internal audit; external audit of a deployed system typically lacks weights, training data and query budget. Scaffolding for third-party access — safe harbours for good-faith research, structured API access — remains unresolved.

Measuring fairness under legal constraints. Enforcing group fairness often requires knowing group membership, which anti-discrimination law and data-protection law both restrict. Proxy-based methods such as Bayesian Improved Surname Geocoding, used in US fair-lending analysis, introduce their own measurement error and their own defensibility problems.

Training-data copyright. Litigation is active across jurisdictions and outcomes differ. The engineering implication is stable regardless of outcome: record provenance and licence per source at collection time, because reconstructing it afterwards is infeasible.

Reading

  • The consolidated text of any statute you rely on, from its official publisher. Secondary summaries, including this page, go stale.
  • NIST AI Risk Management Framework 1.0, 2023 — nist.gov/itl/ai-risk-management-framework
  • Wachter, Mittelstadt and Floridi, Why a Right to Explanation of Automated Decision-Making Does Not Exist in the GDPR, IDPL 2017
  • Selbst and Powles, Meaningful Information and the Right to Explanation, IDPL 2017
  • Raji et al., Closing the AI Accountability Gap, FAccT 2020 — arxiv.org/abs/2001.00973
  • Veale and Zuiderveen Borgesius, Demystifying the Draft EU AI Act, CRi 2021

What to learn next