Align Legal Obligations, Frontier Safety Gates, and Interaction Governance
This page explains how three layers work together: EU AI Act (what the law requires), OpenAI Preparedness Framework (frontier severe-harm release gating), and CRSP AER (per-interaction governance: Ask → Evidence → Release). Use it to design compliant AI deployments that remain safe at runtime—conversation by conversation.
EU AI Act (implementation milestones)
Use these milestones to schedule compliance deliverables and audit gates.
OpenAI Preparedness Framework (v2)
Use PF as your model-level “frontier gate” that informs deployment restrictions.
CRSP AER (runtime governance)
Use AER to enforce scope, uncertainty, and accountability per response.
The three-layer stack
The practical payoff: even if you are compliant on paper and your model is released safely, you still need a runtime mechanism that prevents overreach, scope creep, and “authority leakage” in each output. AER is that mechanism.
EU AI Act: what to operationalize
Operational interpretation
Treat the EU AI Act as a set of obligations you must demonstrate (documentation, transparency, controls), and boundaries you must not cross (prohibited practices and constraints for sensitive deployments). Your internal program should bind these obligations to concrete artifacts: system registers, risk classification, user transparency notices, post-market monitoring, and change-control.
Timeline (practical)
| Date | Milestone | How to use it |
|---|---|---|
| 1 Aug 2024 | Act enters into force | Start governance program + inventory systems |
| 2 Feb 2025 | Prohibited practices + AI literacy obligations apply | Enforce hard blocks + training + UX restrictions |
| 2 Aug 2025 | Governance rules + GPAI obligations apply | Provider documentation + transparency controls |
| 2 Aug 2026 | Fully applicable (general) | Full control coverage across applicable systems |
Keep this table aligned to official EU sources and legal counsel.
OpenAI Preparedness: what to operationalize
PF as your “frontier gate”
Treat Preparedness as your model-level gate that defines: (1) which severe-harm domains you evaluate, (2) how you elicit and measure capabilities, (3) what safeguards are required before deployment, and (4) what conditions trigger delayed release or additional mitigations.
Where PF ends (and AER begins)
Preparedness primarily governs model-level release conditions. It does not, by itself, guarantee that a particular user prompt won’t induce unsafe or non-compliant reasoning. That’s where CRSP AER runs: it applies your constraints at runtime and produces audit-ready traces.
CRSP AER: per-interaction control plane
AER phases (what each must enforce)
| Phase | Goal | Minimum required outputs (typical) |
|---|---|---|
| ASK | Clarify task + constraints + audience | Scope statement; risk posture; prohibited moves |
| EVIDENCE | Ground claims; surface uncertainty | Facts; assumptions; uncertainties; alternatives |
| PROPOSE | Draft provisional artifact | Non-directive output; review points; options |
| ENTITLE | Run defeaters; verify required checks | Defeater scan; completeness checks; decision |
| RELEASE | Publish only entitled content | Final artifact + audit notes + next checks |
Defeaters (examples)
Defeaters are conditions that automatically invalidate entitlement to release. They prevent “helpfulness drift” and provide explainable refusals.
Crosswalk: EU AI Act × Preparedness × CRSP AER
| Control Theme | EU AI Act (legal) | OpenAI Preparedness (model gate) | CRSP AER (runtime gate) |
|---|---|---|---|
| Risk classification | Classify system risk tier and obligations | Threat models + capability categories | Assign interaction risk posture; constrain moves |
| Prohibitions / boundaries | Prohibited practices must be blocked | Restrict deployment above capability thresholds | Defeaters prevent disallowed outputs per prompt |
| Transparency | User-facing transparency duties in relevant contexts | Document evaluations/safeguards | Require disclosures, limits, and audit notes per response |
| Monitoring | Ongoing compliance posture for applicable systems | Safeguard evaluation and post-release monitoring expectations | Required checks: audit fields + monitoring plan + review cadence |
| Change control | Maintain evidence for updates affecting obligations | Re-evaluate safeguards as capability changes | Version tags + entitlement gates before release |
Practical rule: EU AI Act defines obligations, Preparedness defines frontier deployment gates, and AER ensures each output is entitled under your obligations and gates.
Implementation checklist
Governance artifacts
- System register: use-case, owner, intended users, jurisdictions
- Risk map: EU AI Act tier + Preparedness hazard class + internal risk rating
- Scope / Non-scope: explicit prohibitions and “must not” uses
- Transparency text: user notices, logging disclosure, limitations
- Change control: versioning, approvals, rollback triggers
Runtime controls (AER-first)
- ASK gate: enforce constraint declarations (no hidden scope)
- EVIDENCE gate: facts/assumptions/uncertainty required for high-risk outputs
- ENTITLE gate: defeater library + required checks (audit/monitoring)
- RELEASE gate: output only if entitled + audit log written
- Review cadence: committee review of defeater hit-rates and near-miss reports
Template: AER-ready governance prompt
Tip: For regulated domains, attach committee charter + model/system spec as explicit artifacts.
Sources (primary)
Official references
- EU Commission “Shaping Europe’s digital future” — AI Act policy page (timeline milestones)
- European Commission news: “AI Act enters into force” (1 Aug 2024)
- OpenAI Preparedness Framework v2 (PDF, last updated 15 Apr 2025)
- OpenAI blog: “Our updated Preparedness Framework”