What changed on August 2, 2026?

The applicable EU AI Act rules entered their enforcement phase, with the AI Office and national authorities able to act through the mechanisms described by the Commission. Complaint and whistleblower tools give individuals and insiders defined reporting routes. Compliance teams therefore need a repeatable intake, preservation, investigation, and response process rather than a one-time deadline checklist.

Does joining the Code of Practice prove compliance?

The signatory list shows a public commitment to the Code. Operational proof still comes from the organization's systems and records. An authority can ask how a specific interaction was handled, which policy applied, and which actor performed each transparency duty. The signature supports governance context, while event-level evidence supports the factual answer.

Which DeepInspect record helps with a complaint?

The useful record binds an authenticated identity and timestamp to the model route, policy version, request or response classification, and enforcement outcome. That data lets an investigator locate the relevant AI interaction and show the decision that occurred. Application-rendered notices and generation-layer markings require their own evidence from the systems responsible for those functions.

EU AI Act Enforcement Began with Live Complaint Channels

On August 2, 2026, the EU AI Act moved into a new operating phase. The European Commission said the AI Office and national authorities had begun enforcing the applicable rules, while complaint and whistleblower channels opened for people reporting suspected violations. A compliance project that ended with a green spreadsheet on Friday can now receive a case reference on Tuesday morning. The Commission's July 31 announcement also named more than 180 organizations on the first transparency Code of Practice signatory list. Enforcement turns readiness into an evidence-response process.

Three channels can trigger scrutiny

The Commission described an AI Act complaints tool, an AI Act whistleblower tool, and a separate route for downstream providers using general-purpose AI models. Each route changes the intake mechanism, while the evidence problem stays concrete. A complainant may identify a user, a generated output, a date, or a service. The compliance owner then has to locate the interaction, show which policy applied, and explain what the system recorded at that moment. A generic policy document answers none of those event-level facts. The Commission's daily news item dated July 31 anchors the switch from scheduled obligations to an active enforcement process. I think teams that treated August 2 as a finish line built the wrong operating model.

The signatory list records a commitment

Signing the Code of Practice on Transparency of AI-Generated Content records an organizational commitment. The signature cannot produce the underlying interaction history. End-user notices are rendered by the application, machine-readable markings are embedded during content generation, and deepfake detection uses separate technical systems. Those functions sit outside DeepInspect's product boundary. The in-scope evidence layer records that a response-side disclosure policy was active when a particular HTTP AI interaction occurred and preserves the decision attached to that request. That record can support an inquiry, but it cannot substitute for the notice, marking, or detection mechanism itself. Precision here matters because a regulator will separate the published commitment from proof that the organization operated the required process.

A complaint needs an interaction inventory

An investigation starts with retrieval. The organization needs to map the named service and user to the model calls involved, then identify the applicable policy version and response handling. Logs scattered across applications create a manual search with inconsistent identifiers. A per-decision record at the AI request boundary gives the team a stable key: authenticated identity, application route, model, timestamp, policy, classification, and outcome. Picture the evidence packet on an auditor's screen. One row identifies the interaction, another shows the policy decision, and a signed record establishes that the application could not silently rewrite the event after a complaint arrived. That is the operational standard enforcement creates.

Evidence and transparency remain separate duties

The Commission's transparency requirements address disclosures and synthetic-content treatment. Audit evidence supports proof and reconstruction. A gateway can evaluate response-side policy and record the result when traffic crosses its HTTP boundary, while the application remains responsible for showing a user-facing notice. Model providers remain responsible for generation-layer markings where the Act assigns that duty. This division prevents an evidence product from being sold as a watermarking system or a UX control. The previously published Article 50 transparency analysis maps those actor-specific duties. The August 2 readiness article covers the earlier deadline phase.

DeepInspect

DeepInspect provides the in-boundary evidence layer for HTTP AI traffic. It sits between authenticated users or agents and LLM endpoints, evaluates request and response policy, and commits a tamper-evident audit record for each decision. The record includes identity, policy version, classification, outcome, and timestamp, giving a compliance team a searchable interaction inventory when a complaint identifies a specific event.

DeepInspect does not render the application notice, create generation-layer watermarks, detect deepfakes, or sign the Code of Practice. Its role is narrower: enforce configured policy on traffic and preserve evidence that the policy was applied. If your August 2 workstream needs an evidence map, let's talk today.