I like the discussion that Hugging Face's Clem Delangue started around regulating AI at the appropriate layer.
I agree with the principle, but I think the compliance model can be extended. From a systems engineering perspective, it's closer to eight distinct layers, each with different responsibilities and different compliance requirements.
Each layer should have its own compliance contract, rather than applying a single regulatory approach across the entire stack.
The Eight Layers
- Applications: Sector-specific regulations (healthcare, finance, education, employment, consumer protection)
- Agents & Orchestration: Autonomy bounds, tool authorisation, human approval gates, action audit trail, rollback
- APIs & Platforms: Identity, audit logs, abuse prevention, rate limiting and monitoring
- Inference Runtime: Secure execution, telemetry, policy enforcement and model isolation
- Foundation Models: Alignment, safety evaluations, provenance and watermarking
- Model Weights: Transparency, documentation and reproducible research
- Training Data: Provenance, licensing, consent, personal-data handling, retention and deletion
- AI Hardware → trusted execution, attestation and hardware security
Why It Matters
A layered compliance model provides clearer accountability, avoids duplicate regulation, preserves innovation where appropriate, and ensures responsibility sits with the actors best positioned to manage the associated risks.
The Two Layers That Carry the Weight
Two of these layers do more work than the discussion usually gives them credit for.
Training Data. Weights are a consequence of data. Copyright litigation and personal-data law bite on the corpus, not on the artefact derived from it. Placing a transparency duty on weights alone puts the obligation one layer above where the facts actually sit — and the party that can answer "what was this trained on, under what licence, with whose consent" is the curator.
Agents & Orchestration. A system that takes multi-step autonomous action with tool access is a different risk surface from an API that returns text: it acts in the world rather than emitting an output a human then chooses to use. Autonomy bounds, tool authorisation, approval gates and rollback are real compliance primitives, and most stack diagrams have nowhere to put them.
Where a Purely Layered Model Runs Out
The layered view is necessary but not sufficient. Five things sit between the layers rather than inside any one of them:
- Evidence and audit trail — an obligation at one layer is unenforceable unless the evidence survives across all of them.
- Evaluation reproducibility — "run safety evaluations" is not yet specifiable without a standard for what an evaluation is, and whether it repeats.
- Composition risk — every layer can be individually compliant while the assembled system is not. Nobody owns the seam.
- Leaky interfaces — a prompt injection entering at the application layer is defended at the model layer. Layers hold until attacked.
- Role ≠ layer — one firm routinely owns every layer. Liability attaches to actors and market roles (provider, deployer, importer, distributor), not to architectural abstractions.
So the question is two-dimensional: which layer holds the control, and which actor placed the system on the market.
The layered model answers the first and is silent on the second. Most real disputes live in the gap between them.