Pick the EU AI Act obligation that most directly drives runtime guardrail design

The EU AI Act is a regulation, not a single ban. It classifies AI systems into tiers and imposes obligations that scale with risk. A small set of uses are prohibited outright (social scoring by governments, real-time biometric identification with narrow exceptions). A larger set is high-risk: AI used in employment decisions, education, credit scoring, medical devices, law enforcement, critical infrastructure, and several other listed sectors. Most consumer LLM use falls under general-purpose AI rules, which have their own obligations. For a team building an LLM-backed product, the question that matters in interviews is what the high-risk obligations require, because these are the obligations that drive runtime guardrail design. Five obligations matter operationally. **Risk management**, a documented process for identifying and mitigating risks across the lifecycle. **Logging**, automatic records of system operation, retained for a regulated period. **Human oversight**, meaningful human review for high-risk actions, with the ability to intervene or override. **Transparency**, clear information to users about what the system is, what it can do, and its limits. **Post-market monitoring**, ongoing watch on real-world performance with reporting of serious incidents. Each obligation lands on a concrete guardrail choice. Logging means every guardrail decision is recorded. Human oversight means an escalation path exists. Transparency means UI surfaces the system's nature. The other options in the question (a blanket ban, an EU-models-only rule, a CoT ban) misstate the law.

The EU AI Act is **risk-tiered**, not a single ban. The obligations that drive runtime guardrail architecture are the **high risk system obligations**, which apply to AI used in regulated sectors (employment, education, credit, critical infrastructure, law enforcement, medical devices, certain border-control uses, and several others). Most production LLM applications either fall under these directly or are downstream of general-purpose AI rules that have analogous obligations. Five obligations translate into concrete guardrail design choices: - **Risk management** (Article 9). A documented process across the lifecycle for identifying, assessing, and mitigating risk. Operationally this requires a written threat model, a guardrail design that traces back to that threat model, and evidence of testing. - **Data governance and logging** (Articles 10 and 12). Automatic logging of system operation, retained for a defined period. Operationally every guardrail decision must produce a structured audit record, what fired, why, what the outcome was, what the inputs were (subject to data-minimisation). - **Human oversight** (Article 14). Meaningful human review with the ability to intervene, override, or halt. Operationally this means an escalation path for high-risk actions, a UI that surfaces relevant context to the reviewer, and SLAs on review. - **Transparency** (Article 13). Clear information to users about the system's nature, capabilities, and limits. Operationally this means a system card, in-product disclosures, and consistent labelling. - **Post-market monitoring** (Article 72). Ongoing watch on real-world performance, with serious-incident reporting. Operationally this means a dashboard of guardrail effectiveness metrics, a feedback loop into the risk-management process, and an incident-reporting workflow. The other options in the question misstate the law. There is no blanket ban on LLM deployments. There is no EU-models-only requirement.