Keep the deployment inventory and the regulatory record separate, then reconcile them through an accountable handoff. A model-registry entry, a completed assessment and a registration submission prove different things. Your release process should expose which system, intended purpose, responsible actor and approved evidence snapshot belong together—and stop promotion when that relationship cannot be demonstrated.
This is an engineering design, not legal advice or a determination that your system must be registered. Counsel must confirm classification, actor, applicable provisions, transition rules and the correct submission route. Nothing here assumes that a production registry API is available.
Establish the source version before building the form
The AI Act on EUR-Lex links to a consolidated version dated 27 July 2026. The Digital Omnibus amending regulation matters directly to the data contract: Article 1(42) deletes points 7 and 9 from Annex VIII Section B. Do not copy an old registration checklist unchanged into your application.
The Commission's Article 49 Service Desk page explicitly reproduces the original Act. It is a useful navigation aid, not a substitute for the amended law. In particular, removing two Section B submission fields does not mean removing the entire Article 49(2) registration route or deleting your internal classification reasoning.
Timing needs the same discipline. The amendment's Article 1(40) changes the application of Chapter III Sections 1–3, with separate dates for Annex III and Annex I classifications. Article 49 sits in Section 5. Do not assign a universal registration deadline by copying a headline about deferred high-risk requirements. Store a counsel-approved applicability decision for the actual provision and system, including relevant transition rules. The Commission overview supplies policy context; it is not your release authorisation.
Route by actor and system, not by model family
Article 49 distinguishes provider registration, specified public-authority deployer registration, restricted records and national registration. It does not instruct every enterprise to register every model weight file. The matrix below is a routing aid based on the statutory structure, not a complete legal applicability assessment.
| Actor and scope | Route to review | Engineering handoff |
|---|---|---|
| Provider or applicable authorised representative; Annex III high-risk system except point 2 | Article 49(1), EU database | Bind system identity, intended purpose and the applicable Section A evidence |
| Provider or applicable authorised representative; Article 6(3) not-high-risk conclusion | Article 49(2), EU database | Bind reviewed conclusion and current Section B submission fields |
| Public authority, Union institution/body/office/agency or person acting on its behalf; applicable Annex III deployment except point 2 | Article 49(3), register actor and system use | Connect deployer evidence to the provider's system entry |
| Specified Annex III points 1, 6 and 7 systems in law enforcement, migration, asylum or border control | Article 49(4), secure non-public section | Apply the restricted field set and access boundary |
| Annex III point 2 high-risk system | Article 49(5), national registration | Record the validated national route and responsible submission owner |
| Other system or actor configuration | No automatic route inferred from this matrix | Obtain an explicit applicability decision; do not label unknown as exempt |
The restricted route is not a generic option for commercially sensitive systems. Equally, being a private company does not settle the question: a company may be a provider or may act on behalf of a public authority. Capture the legal entity and its role in this specific system relationship. A vendor's registration is not automatically evidence of a deployer's registered use.
Model three linked records
Start with the AI applicability graph for classification inputs and ownership. This article addresses the next boundary: how an approved decision becomes an accountable external-record handoff and remains aligned with deployment changes.
Record one is the deployment snapshot. Give the system a stable internal ID distinct from the model name. Link release digests, configuration, operating environment, process owner and approved intended-purpose revision. One model can support several systems; several deployment instances can belong to one reviewed system identity. Do not invent a one-model-to-one-registration relationship.
Record two is the regulatory decision. Include the responsible legal entity, actor role, classification decision reference, provision and route, reviewed source version, applicable-date reasoning, reviewer and review trigger. The platform team owns field validation and enforcement. The authorised compliance/legal function owns the legal assertions. Keep unknown, not applicable and awaiting review as distinct states.
Record three is the submission evidence. Store the approved payload revision, submitting actor, submission time, official reference or receipt where available, returned status, readback evidence and the system identity to which it applies. A local job ID proves only that your job ran. It must never populate the external-reference field by default.
Use immutable revisions with a separate pointer to the current approved state. A model nameplate and rollback bundle provide a complementary technical identity pattern. They do not replace registration, conformity assessment or the approved legal decision.
Reconcile semantic fields, not entire documents
Define a small canonical comparison object: internal system ID, responsible entity, role, intended-purpose revision, approved external identity, lifecycle status and route. Keep model/container digests as technical change signals. A changed digest should trigger the configured review; it does not automatically establish a new legal system or a duty to create another registration.
Map each external submission field to its owner and source. For example, provider identity comes from the controlled entity record; trade name and unambiguous system reference come from the product identity record; intended purpose comes from the approved purpose statement. Relevant Annex VIII sections require submitted information to be kept up to date. Your implementation needs a controlled update path, not a nightly blind overwrite.
For the Article 49(2) route, retain internal classification reasoning even though the amendment deletes Section B point 7 from the submission list. Internal evidence and mandatory export fields are different schemas. Likewise, retain deployment geography where operationally useful without continuing to describe deleted Section B point 9 as a current required submission field. This prevents a legal amendment from accidentally erasing engineering context.
Do not hash a PDF and call that semantic reconciliation. Formatting changes can alter a file hash without changing purpose, while two unrelated files can repeat the same generic system name. Compare typed fields and retain a checksum of the underlying artifact as an integrity control, not as proof of factual accuracy.
A controlled handoff workflow
1. Freeze the candidate snapshot. The release owner selects exact deployment, purpose and decision revisions. Reject missing owners, mutable evidence links and unresolved applicability.
2. Build a route-specific preview. Export only reviewed fields for that route. Show the submitter what will leave the organisation, including contact information and any assessment summaries. Keep restricted operational evidence outside the export unless specifically required and authorised.
3. Approve and submit. An authorised actor uses the verified official mechanism. Until a supported interface is established, use a controlled manual process with an evidence upload—not a fictional REST endpoint or unreviewed browser automation.
4. Read back and reconcile. A second reviewer compares the official entry or available acknowledgement with the approved snapshot. If a submission is merely received, preserve that status. Do not rename it accepted or compliant.
5. Bind the evidence to release. The promotion gate evaluates the reviewed requirement and its evidence. Changes that affect approved scope reopen review. An unavailable external system should create a visible exception workflow, never a fabricated receipt.
6. Monitor drift and retirement. Detect unlinked deployments, stale purpose statements and orphaned external references. Retirement needs a lifecycle reconciliation too; deleting the deployment record must not destroy the history used to explain the previous state.
Test the failure boundaries before enforcement
| Test case | Required result | Evidence retained |
|---|---|---|
| Same model deployed for a different intended purpose | Hold promotion for scope review | Old and new purpose revisions plus reviewer decision |
| Submission times out after sending | Investigate existing submission before retry | Payload revision, attempt record and official reference if available |
| Receipt exists but identity differs | Keep reconciliation failed | Field-level discrepancy and assigned owner |
| Public lookup cannot find a restricted record | Use authorised restricted evidence path | Access decision and appropriate readback evidence |
| Legal field mapping changes | Version export schema and re-evaluate affected records | Source amendment and mapping diff |
| Deployment is retired while external record remains active | Open lifecycle reconciliation task | Retirement event, owner and closure evidence |
Do not let registration checking become a runtime dependency for every inference. As an architectural recommendation, place it at promotion and relevant change boundaries, with scheduled reconciliation. The trade-off is bounded staleness between checks. Define review intervals from the system's change rate and consequence of mismatch, and keep immediate triggers for approved-scope changes.
Avoid automatic production shutdown solely because a portal is unavailable. Existing-operation decisions need a separately approved continuity and incident policy. A release hold and a runtime stop are different controls, particularly in industrial environments where an abrupt stop can create its own risk.
Acceptance checklist for a first implementation
Check identity: can a reviewer navigate from one live deployment to the exact system, intended purpose and responsible entity without relying on a display name?
Check authority: are classification approval, export approval, submission and reconciliation explicitly assigned? Separate duties where your risk policy requires it.
Check evidence: are internal review, submitted, acknowledged and reconciled states distinct? Can a failed retry be investigated without another submission?
Check data handling: do public and restricted routes have different export allowlists? Are evidence access and retention approved rather than inherited from the source code repository?
Check change handling: can a changed purpose, legal entity, source version or lifecycle state reopen the right review without rewriting historical approvals?
Check operational cost: measure unresolved mismatches, age of pending handoffs and review effort. Report these as process observations, not as a compliance score or proof that registration makes the AI safe.
Start with a reconciliation exercise
Choose one existing deployment and reconstruct its identity, approved purpose, actor decision and external-evidence position. Record every missing join and resolve ownership before buying another governance tool. I can help your platform and compliance teams design that evidence contract and implement a bounded release gate; legal classification and submission obligations remain with qualified counsel.
Primary sources and scope
EUR-Lex: original AI Act and link to current consolidation — Article 49 and Annex VIII structure; checked alongside the amending instrument, not treated as unchanged law.
EUR-Lex: Digital Omnibus on AI, operative amendments — Article 1(40) on application provisions and Article 1(42) on Annex VIII Section B deletions.
European Commission: Article 49 Service Desk — accessible original-text routing reference, explicitly not an amended-law substitute.
European Commission: AI Act overview — implementation context. Source review: 10 September 2026. This article does not verify a live submission portal, establish a universal deadline or provide legal advice.
