Enforcement begins after the obligation

Organizations often treat enforcement as the moment compliance begins. Work accelerates near the date, dashboards turn red, and controls are described as preparations for a new obligation. That framing can be wrong in two directions: the duty may already apply, and the enforcement date may govern only certain rules, actors, or powers. A calendar milestone needs a legal scope and an operational state.

The Commission's GPAI guidance says obligations for providers of general-purpose AI models entered into application on August 2, 2025, while Commission enforcement powers apply from August 2, 2026. The AI Act Service Desk timeline separately describes the broader August 2026 enforcement and transparency milestones. The distinction is a useful operating lesson beyond one regulation.

A control program should keep four dates: when the rule applies, when a particular system or model enters scope, when enforcement powers activate, and when transitional treatment ends. Those dates can differ. Attaching one deadline to the entire program can make a legacy model look immediately due or a new model look safely deferred.

Build a dated scope ledger

For every obligation, record the actor, covered artifact or activity, triggering event, application date, enforcement authority, transition, interpretation source, and evidence owner. Link the system inventory and release history so the organization can determine which models or systems were placed on the market before or after a relevant boundary.

The ledger should distinguish ready, operating, evidenced, disputed, and not applicable. Ready means a control exists. Operating means it runs for the scoped population. Evidenced means the organization can show that state for a date and release. Disputed means interpretation remains open. These statuses prevent a document completed last year from standing in for a control that has never been observed in production.

An enforcement date is a change in consequence, not a substitute for the history of the obligation.

Do not backfill certainty. If the organization cannot reconstruct when a control became effective, record the evidence frontier and the earliest proven date. A newly created policy should not be presented as though it governed earlier releases. Honest gaps are easier to remediate than a timeline whose confidence exceeds its records.

Plan for authority requests before they arrive. Identify who receives a request, which evidence can be produced, which confidential material needs protected handling, and how the response stays tied to the correct model and obligation. A mature response path reduces the temptation to assemble a compliance narrative from whichever documents are easiest to find.

Board and executive reporting should show scope and residuals, not only countdowns. Report obligations already operating, controls whose evidence is incomplete, interpretations awaiting decision, models under transition, and actions that must occur before enforcement. The date matters because it changes risk; the work matters because it changes the underlying state.

Make the obligation operational

Begin with the separate application, scope-entry, enforcement, and transition dates for each actor, model, system, and obligation. Express it as a control object rather than a policy summary: scope, triggering condition, applicable system or model version, permitted exception, effective time, evidence source, and the consequence when the control cannot establish compliance. This lets engineering, product, legal, and operations examine the same boundary without pretending their responsibilities are interchangeable.

The minimum receipt should retain dated inventory, controlling source and version, applicability decision, control activation, first verified operating receipt, transition basis, and residual gap. Keep the record proportionate and protect confidential information, but make it possible to determine which rule, artifact, system version, and accountable decision governed the event. A folder of undated screenshots may show that work occurred; it rarely proves that the operative control held for the affected release.

Test the implementation by sampling releases on both sides of each date and reconstructing which obligations, controls, authorities, and transitions applied without using today's state as a proxy. Include ordinary cases, boundary cases, degraded dependencies, and known exceptions. Preserve the starting state, observed output, machine-readable evidence, user-visible result, and any human intervention. Re-run the test after changing a model, content pipeline, interface, standard, provider, or policy interpretation.

The compliance program owner with the model and system inventory owners should decide whether the evidence supports continued operation, a narrower scope, a compensating control, or a hold. The owner needs authority over the affected release and access to the evidence. Record unresolved interpretation separately from a technical defect so an engineering patch does not masquerade as a legal conclusion.

Monitor both presence and effectiveness. A marker can exist but be stripped downstream. A disclosure can render but arrive after exposure. A document can be submitted but refer to an obsolete model. Pair a control-presence measure with a consequence or comprehension test, give the claim a review date, and reopen it when a dependency changes.

Maintain a dependency register for the control. Model endpoints, editing pipelines, content formats, user interfaces, identity services, submission portals, vendors, and external standards can change the evidence without changing the policy text. Name which changes invalidate the last test and which monitoring signal proves that the dependency remains inside the reviewed state.

Exercise the exception path as carefully as the ordinary path. Record who can invoke it, which facts they must supply, how long it lasts, what capability or distribution is reduced, and which compensating evidence remains. An exception without expiry and re-entry criteria becomes a second operating model that can silently outlive the reason it was approved.

Keep public and executive claims no broader than the tested boundary. Say which systems, releases, formats, routes, and dates the evidence covers, and identify material exclusions. When a control fails or a dependency moves, update the claim and the remediation record together. A transparent limitation protects more credibility than a universal statement built from a narrow passing test.

— Dispatches · Summit Cognitive