The EU AI Act is turning AI compliance into an evidence pipeline, not a policy document

The 2 August 2026 transition did not make every AI Act provision share one deadline. The timeline remains layered, and the July AI Omnibus extended selected high-risk-system dates. The change is that important transparency duties now apply and enforcement powers cover general-purpose AI obligations.

That makes compliance a release-management problem. An organization must know which rules apply to which system version, show the control in production and preserve evidence that it worked.

The legal memo remains necessary, but the decisive record is the evidence chain connecting interpretation to configuration, test, approval, delivery and monitoring.

A business may consume a third-party model, add retrieval and tools, sell the resulting system, operate it for customers and distribute generated content. Those activities can create different responsibilities across the value chain.

The same model can support an internal assistant, public chatbot, hiring workflow or regulated product. Model identity alone does not determine the system risk or deployer duties.

Each deployment record should therefore name the provider, system owner, deployer, intended purpose, affected users, market and decision authority.

GPAI providers must maintain technical documentation and provide information that helps downstream system providers understand capabilities and limitations. Downstream teams need that information to design tests, safeguards and user communication.

A model card that cannot be tied to a specific API or weight revision is weak evidence. Providers and integrators need stable identifiers, change notices, evaluation scope and known limitations.

System providers still need their own integration dossier covering prompts, retrieval, tools, permissions, interface behavior and human oversight.

Article 50 covers several situations, including informing people when they interact with certain AI systems and marking specified synthetic outputs in a machine-readable form. Deepfakes and some public-interest text also require disclosure under the law’s conditions and exceptions.

The control must exist where the interaction or content is delivered. A notice hidden in terms is not equivalent to an in-context disclosure, and provenance attached to an original file may not survive distribution.

Teams should test visible and machine-readable disclosure across export, publishing, syndication, recompression and re-upload.

C2PA Content Credentials can carry signed assertions about origin and editing history. They can support machine-readable transparency and help recipients inspect a content chain.

They do not prove that a depicted event is true, that every edit was disclosed, or that an unsigned file is deceptive. Credentials may also be stripped by platforms or broken by unsupported transformations.

A defensible implementation combines protected signing keys, verification, visible disclosure, survival testing and clear communication about what the signal does and does not establish.

The evidence bundle should identify the model and system configuration, applicable obligations, evaluations, risk decision, disclosures, security controls, owners, exceptions and approval.

Automation should collect machine-generated facts such as commit, model revision, test run and deployment identifier. Human reviewers should approve scope, residual risk and exceptions.

The gate must fail closed when mandatory evidence is missing, while a governed exception process handles urgent releases without normalizing permanent bypasses.

AI systems change after release through provider updates, retrieval content, tool permissions and policy changes. A static approval cannot explain an incident unless runtime events carry the active configuration identifier.

Logs should link outputs, actions, human overrides, complaints and incidents to the model, prompts, tools, data sources, policies and release owner in force at the time.

This traceability supports investigation, corrective action and regulator response while reducing the temptation to reconstruct production from memory.

A smaller organization does not need a vast governance platform to begin. It needs a reliable inventory, role classification, model and system versioning, deployment-specific risk record, disclosure component, release checklist and incident log.

The control set should expand with autonomy, affected people, decision consequence, distribution scale and regulatory classification.

Proportionality should reduce unnecessary process, not eliminate evidence. A short current record is stronger than a large policy library that does not match production.