Updated 17 October 2026. This article has been revised to separate the policy timeline from the product argument. See the current AI Act timeline for the category-specific dates and primary reference.
A technical standard can help a team interpret what good evidence looks like. Waiting for one does not prevent the team from understanding its own system. Those are different kinds of work.
Separate standardisation from system knowledge
Begin with what the team can establish directly: the purpose of the system, its data dependencies, permitted actions and known failure modes. Keep these records factual. They should describe the current product rather than anticipate a favourable interpretation of a future standard.
Next, identify the precise question for which additional guidance is needed. It might concern a conformity route or the adequacy of a particular assessment. Name that question and its reviewer. “Waiting for standards” should not be an umbrella covering every unfinished task in the programme.
An illustrative team can test whether a revoked credential still permits an action without claiming that the test demonstrates legal conformity. The result is useful engineering evidence. Its significance for a particular obligation is a separate assessment.
When guidance changes, revisit the mapping between evidence and requirements. Avoid rebuilding the entire inventory because a reference document changed. Good records make revision cheaper; they do not make interpretation unnecessary.
| Decision | Evidence to request |
|---|---|
| Known system behaviour | Direct observations and tests |
| Open interpretation | Specific question and reviewer |
| Changed guidance | Updated mapping and affected evidence |
What to do with this
Build the parts you can justify, keep uncertainty visible and avoid selling preparation as certification. A standards dependency should have a name and an owner, not a blanket exemption from doing the work.
Record the decision, the responsible owner and the evidence still missing. The decision-record example shows a lightweight way to do that. Where a claim concerns system behaviour, connect it to evaluation evidence. These are proposed product practices, not a finding that a system complies with the law.
Primary timeline reference: European Commission, AI Act. The operational recommendations above are my analysis.
