EU AI Act General Counsel Checklist: Actions Before December 2, 2027
As of November 2026, 2 December 2027 is the date from which the Commission states that high-risk AI systems face strict obligations before they can be placed on the market. The AI Omnibus, in force since 27 July 2026, set it. A General Counsel should inventory AI systems, classify roles and risk, assign owners for risk management, human oversight, record-keeping and vendor terms, and require every control to produce evidence of what each system was permitted to do and what it did. This guide is not legal advice.
Where December 2, 2027 fits in the phased timeline
Regulation (EU) 2024/1689 applies in phases. Governance rules and obligations for general-purpose AI (GPAI) models have applied since 2 August 2025. GPAI models placed on the market before that date must comply by 2 August 2027. The AI Omnibus, proposed on 19 November 2025, agreed provisionally on 7 May 2026 and in force since 27 July 2026, amended the Act and moved the high-risk dates.
The Commission states that, starting on 2 December 2027, high-risk AI systems will be subject to strict obligations before they can be put on the market, including adequate risk assessment and mitigation systems. The Commission's original proposal distinguished stand-alone high-risk systems (2 December 2027) from high-risk systems embedded in products (2 August 2028). Confirm which date applies to each system when you classify it.
Two nearer dates come from the May 2026 provisional agreement: 2 December 2026 for providers to implement transparency solutions for artificially generated content, and 2 August 2027 for national regulatory sandboxes. Treat them as separate workstreams from the high-risk programme, and check whether any touch your vendor contracts.
What the deadline concerns and who is in scope
The Act applies to public and private actors inside and outside the EU that place an AI system or GPAI model on the EU market, or put an AI system into service or use it in the EU. A non-EU enterprise that uses AI systems whose outputs reach the EU should not assume it is outside scope.
For high-risk systems, a risk management system must be established, implemented, documented and maintained. The recitals add that comprehensible information on how these systems were developed and how they perform throughout their lifetime is essential for traceability, compliance verification and post-market monitoring. That requires keeping records and making technical documentation available. In practice, your evidence must cover both system design and behaviour over time.
Supervision is two-tiered. National competent authorities oversee and enforce the rules for most AI systems. The AI Office governs GPAI model providers and a subset of AI systems, which the AI Omnibus extended to certain systems built on general-purpose models and those embedded in large online platforms and search engines. Identify which authority is likely to be your counterpart for each system. The Commission has also published guidelines on classifying systems as high-risk, with practical examples.
Assigning ownership across legal, risk, security and engineering
The Act does not prescribe internal owners, so this is a governance decision. A workable split gives legal accountability for role and risk classification, contract terms and regulator engagement. Risk owns the risk management system and its register. Security owns access, data handling and the technical means of restricting what AI systems can do. Engineering owns implementation of oversight steps, record generation and retention.
Each obligation should have one accountable owner and a defined evidence artefact. Without that pairing, a policy exists but cannot be shown to operate. Review the matrix whenever the Commission publishes new standards or guidance. The original high-risk timeline was tied to the availability of standards and tools, and dates have already moved during the legislative process.
Run a regulator-request drill. Where a market surveillance authority finds non-compliance, it must without undue delay require corrective action, withdrawal or recall. The period is set by the authority and is in any event within the shorter of 15 working days or what the relevant Union harmonisation legislation provides. Measure how long your teams take to assemble system records, risk documentation and oversight decisions for one system, and treat the result as a baseline to improve.
Where runtime policy enforcement can support the obligations
Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Policy is enforced at runtime, not reviewed after the fact: each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval. The enforcement generates continuous audit-ready evidence mapped to the EU AI Act, among other frameworks. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.
This maps most directly to human oversight, where escalation for approval creates a record of the decision, and to record-keeping, where each enforcement decision is evidence of what a system was permitted to do. It can also give your risk management documentation operating evidence that named mitigations ran. Approved proof points include 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live production traffic, 100+ models under one policy plane, and 30+ GB of audit evidence generated per day.
The limits matter. Trussed's scope is individual interactions and tool calls. It does not provide model provenance, dataset provenance or end-to-end tracing of agentic workflows, and it does not replace risk classification, technical documentation, vendor terms or legal judgment. It supplies runtime evidence that those workstreams can reference.
From written policy to demonstrable compliance
Inventory and classify
Know which systems are in scope, your role for each, and whether they are high-risk.
Assign ownership
Name accountable owners in legal, risk, security and engineering.
Enforce at runtime
Apply policy where the AI system acts, not only on paper.
Retain evidence
Keep durable records that can be retrieved when a regulator asks.
Test your controls against the evidence a regulator may request
Review how enforcement in the execution path produces audit-ready evidence for your AI systems.
See How Evidence Is Produced