August 2, 2026 is chiefly a transparency milestone under the EU AI Act, not a blanket date when every high-risk obligation suddenly applies.
For production teams, the practical question is whether the system can produce evidence while it runs.
Read the schedule before designing controls
General-purpose AI provider obligations have applied since August 2, 2025. The next major point, August 2, 2026, principally concerns transparency. Standalone Annex III obligations then move to December 2, 2027, while Annex I product obligations move to August 2, 2028.
That sequence changes what engineering teams should make testable now. Treating 2026 as one universal high-risk deadline collapses distinct phases and makes it harder to connect a control to the obligation it is meant to support.
The reported enforcement timeline also gives teams a concrete transparency case: providers of systems that interact with people must make that interaction clear. The implementation question is therefore observable, not theoretical. Can the deployed experience demonstrate the relevant transparency behavior, and can the team retrieve evidence of it?
Classification still comes first. Confirm the organization’s role, the system classification, and the applicable duties with counsel before turning this engineering pattern into a release gate.
Turn each AI decision into an evidence path
Slides can explain governance intent, but they are risky as the primary evidence source when an auditor asks for live proof. Production evidence should be generated continuously through logging, lineage, evaluations, access decisions, and human review.
At Van Data Team, we begin by mapping five connected parts of the operating path:
- The decision the AI system supports and the output associated with it.
- The relevant data and the lineage that connects it to that decision.
- The tools involved and the evaluation results available for review.
- The access decisions and handoffs that shaped what happened.
- The human review step and the accountable owner for the path.
Once that map exists, treat its records as pipeline outputs. The goal is not to accumulate the largest possible archive. It is to preserve a retrievable chain that connects a specific decision to the controls and reviews around it.
A log without lineage leaves the source unclear. An evaluation detached from the decision cannot show which output it assessed. A human approval without the surrounding handoffs says little about how the system reached that point. The evidence becomes useful when those pieces describe the same path.
Make Compliance-as-Code executable
Compliance-as-Code does not mean pretending legal interpretation can be reduced to configuration. It means expressing the expected evidence as checks that engineering and governance teams can run consistently.
A readiness runbook should walk through one production decision and ask whether the team can retrieve its logs, reconstruct its data lineage, locate the relevant evaluation, show the access decision, and identify the human review. If an artifact cannot be produced, the runbook has found an operational gap rather than another slide to rewrite.
For an interaction involving a person, the same exercise should include the transparency behavior. The point is to test what the system did and what proof exists, not simply whether a policy says the control should exist.
Keep ownership attached to the trace
Continuous evidence still needs a human operating model. The decision, data, tools, and handoffs need an accountable owner who knows where proof is generated and how it is reviewed.
This is also the honest tradeoff. Runtime evidence turns governance into recurring delivery work. Logging, lineage, evaluations, access decisions, and human review have to remain connected as the production path changes. A one-time documentation sprint cannot provide that continuity.
An auditable pipeline can still support the wrong conclusion if the underlying classification or role is wrong. Engineering evidence complements legal analysis; it does not replace it.
The stakes make that discipline material: penalties can reach EUR 35 million or 7% of global annual turnover, whichever is higher. That ceiling is not a substitute for understanding the applicable duty, but it is a reason to make proof reproducible.
Use the transparency phase as a readiness test
The August 2026 transparency phase is a practical point to validate evidence generation before the later high-risk phases arrive. It does not pull the Annex III or Annex I dates forward. It gives teams a current production concern against which to test their pipeline, checklist, and runbook.
Start with one real decision path. Map it, retrieve each artifact, record the missing connections, and assign the gap to the accountable owner. Then repeat the exercise as the system and its obligations evolve.
If you had to prove one production AI decision tomorrow, which artifact would be hardest to retrieve: its lineage, evaluation result, access decision, or human review?
📖 Read the full guide → EU AI Act Compliance in Production: Auditable Pipelines
Top comments (0)