Status note (19 July 2026): AI compliance is not a single middleware product or a universal checklist. This guide separates binding law, regulator guidance, voluntary frameworks, and internal engineering controls. It uses the EU AI Act and China's content-labeling rules as examples, but every deployment still needs a current jurisdiction, role, version, and applicability review. This is educational material, not legal advice.
Key Takeaways
- Classify the system by intended purpose and role before selecting controls.
- Treat 2 August 2026 as a date in the EU AI Act timetable, not proof that every AI system has the same deadline.
- NIST AI RMF 1.0 and its Generative AI Profile are useful voluntary risk-management references, not a substitute for law.
- China's labeling measures distinguish explicit presentation from implicit metadata and apply to specified service and dissemination contexts.
- Build auditable evidence: decisions, data lineage, evaluations, approvals, incidents, changes, and deletion or retention outcomes.
- A gateway, log, filter, or watermark can implement a control; none of them alone establishes legal compliance.
Start With Scope, Role, and Version
Before writing a technical checklist, create a one-page applicability record:
| Question | Evidence to retain |
|---|---|
| What does the system do, and for whom? | Intended purpose, user journey, decision affected, deployment diagram |
| Who is the provider, deployer, importer, distributor, or affected operator? | Contract, entity, geography, service boundary |
| Which data, model, and downstream components are involved? | Model ID and version, datasets, processors, vendors, dependencies |
| Which rule or standard is being applied? | Exact regulation, article, guidance, standard revision, access date |
| What is the classification and why? | Written rationale, exclusions considered, legal/compliance review |
| What changes can invalidate the decision? | New capability, new user group, new country, model update, incident |
This record prevents a common failure mode: copying controls from a high-risk use case into a low-risk product while missing a duty that applies to the actual role. It also makes later audits reproducible.
EU AI Act: Read the Timetable and Risk Categories Together
Regulation (EU) 2024/1689 uses a risk-based structure. It addresses prohibited practices, high-risk systems, transparency duties for certain systems, and obligations for general-purpose AI models. The date and obligation depend on the relevant category, transitional provision, and current consolidated text.
| Topic | Engineering question | Do not assume |
|---|---|---|
| Prohibited practice | Does the intended use fall within a prohibited practice? | That a content filter can legalize the use |
| High-risk system | Does the purpose and product context match Article 6 and Annex III, or a safety-component route? | That every model used in a regulated sector is automatically high-risk |
| Transparency | Are users informed when the applicable transparency provision requires it? | That a generic “AI generated” badge satisfies every duty |
| General-purpose model | Is the team a provider or downstream deployer, and which model obligations apply? | That open weights remove provider obligations |
| Penalties | Which Article 99 category, entity, and calculation rule applies? | That 7% or EUR 35 million is a universal fine |
The Act's timetable includes important provisions applying from 2 August 2026, but a compliance plan should cite the exact article and transition rule. Monitor the consolidated regulation, Commission guidance, and adopted amendments; do not publish a countdown as if it were a complete legal analysis.
Evidence-oriented high-risk preparation
| Control area | Useful evidence | Technical pattern |
|---|---|---|
| Risk management | Hazard register, residual-risk decisions, owner and review date | Versioned risk register linked to releases |
| Data governance | Provenance, quality checks, representativeness, retention | Dataset manifest and approval gate |
| Documentation | Model/system description, limitations, instructions | Generated documents from reviewed source fields |
| Logging | Events needed for traceability with privacy controls | Append-only or tamper-evident store, access audit |
| Human oversight | Escalation policy, override authority, workload limits | Review queue with reason codes and cancellation |
| Accuracy and robustness | Slice results, uncertainty, failures, red-team records | Reproducible evaluation harness |
| Cybersecurity | Threat model, secrets, access, incident response | Server-side authorization, isolation, rotation, recovery |
These artifacts support compliance work; they do not replace a conformity assessment or a competent authority's interpretation.
China: Content Labeling Is Scope-Dependent
The Measures for Labeling AI-Generated Synthetic Content (2025) distinguish explicit labels visible to users from implicit labels stored in file metadata. They took effect on 1 September 2025 and apply in the service and dissemination contexts described by the measures and related rules. The exact obligation depends on the provider's role, content type, delivery path, and applicable standards.
An implementation should therefore model provenance explicitly:
{
"content_id": "stable-content-id",
"generated": true,
"provider_code": "verified-provider-code",
"model_id": "verified-model-id",
"created_at": "2026-07-19T10:00:00Z",
"label_policy_version": "verified-policy-version"
}
This is an internal evidence shape, not a claim that every field or JSON representation is legally prescribed. Keep the source asset, transformations, export path, visible-label decision, metadata result, and any removal or tampering event. For audio, images, video, and interactive scenes, test the label through download, copy, transcoding, and re-upload paths.
Do not write “algorithm filing,” “annual safety assessment,” or “dual watermark” as universal requirements. Determine whether the service falls under the Algorithm Recommendation Provisions, Deep Synthesis Provisions, Interim Measures for Generative AI Services, the 2025 labeling measures, or a sector-specific rule. A legal review should resolve overlaps and exceptions.
NIST: A Voluntary Risk Vocabulary
NIST AI RMF 1.0 organizes work around GOVERN, MAP, MEASURE, and MANAGE. NIST AI 600-1 is a companion Generative AI Profile. NIST describes the framework as voluntary and says AI RMF 1.0 is being revised. Use it to structure ownership, risk hypotheses, evaluations, and evidence; do not describe it as a mandatory “3.0 middleware” requirement or as an EU legal mapping that guarantees compliance.
| NIST function | Engineering artifact | Review question |
|---|---|---|
| GOVERN | RACI, policy register, exception log | Who can approve, pause, or retire the system? |
| MAP | Use-case and data-flow inventory | What harms and affected groups are in scope? |
| MEASURE | Evaluation manifest and incident metrics | Are metrics valid for the actual task and slice? |
| MANAGE | Mitigation plan and release decision | Did the mitigation reduce risk without hiding uncertainty? |
Runtime Architecture: Controls With Clear Boundaries
Request
-> identity and purpose check
-> input handling and data minimization
-> model/tool execution
-> output and provenance checks
-> policy decision or human review
-> redacted evidence record
-> response, incident, or rollback
Logging every raw prompt and response is neither always lawful nor always useful. Define a retention purpose, redact secrets and personal data, restrict access, record policy versions and hashes where appropriate, and test deletion or legal-hold behavior. Enforce authorization at the tool and data boundary; a gateway or model card cannot grant permission.
Useful control families include:
- Inventory and provenance: model, data, prompt, policy, dependency, and release identifiers.
- Evaluation: representative slices, human review, robustness, security, fairness, and uncertainty.
- Operations: rate limits, cancellation, incident response, rollback, vendor change detection.
- Transparency: user notices, content labels, instructions, limitations, and complaint paths.
- Evidence: signed or tamper-evident records with privacy-aware retention and access review.
A Reviewable Implementation Roadmap
Phase 1: Applicability
- Freeze the jurisdiction, service role, model versions, and intended purpose.
- Record classification decisions and unresolved legal questions.
- Map each applicable obligation to an owner and an evidence artifact.
Phase 2: Engineering Controls
- Add server-side identity, object authorization, data minimization, and secret handling.
- Version evaluation fixtures, policy rules, model IDs, and labeling behavior.
- Implement bounded logging, human escalation, incident handling, and rollback.
Phase 3: Verification
- Test normal, adversarial, multilingual, export, deletion, and failure paths.
- Re-run checks after model, prompt, vendor, geography, or data changes.
- Have qualified legal and domain reviewers approve the applicability record.
Conclusion
World-class compliance engineering is disciplined separation: law from guidance, provider duties from deployer controls, visible labels from metadata, and evidence from conclusions. Start with the exact source and role, build only the controls that address an applicable duty, and keep the classification and evidence current. No architecture diagram, framework name, dashboard, or percentage can substitute for that review.