Disclosure: This is Ariftly engineering guidance, not legal advice, certification, or evidence of a compliance product or customer deployment. The seven stages and twelve fields are an authored framework
A practical AI control is a transition rule plus evidence that the rule ran. This framing is useful even when the workflow does not fall within the EU AI Act's high-risk regime. It prevents teams from mistaking application architecture for legal classification.
Start with an applicability record. Store the system's intended purpose, operating entity, potential provider and deployer roles, location of use or output, decision category and assessed legal scope. Add a classification status such as review_pending, high_risk_annex_iii, article_50_trigger or not_triggered. Those strings are local implementation labels, not regulatory classifications in themselves. Require a named owner and the version of the law used at assessment.
Describe the execution chain. A single run can contain multiple machine and human events. Give each event a unique ID, reference its run, timestamp it, identify its stage and attach references to the relevant inputs or results. Resist the temptation to save everything in one giant transcript. Large unstructured logs are difficult to review and may create unnecessary data-protection risk. Instead, link to appropriately secured artifacts with expiry and retention rules.
Separate AI interpretation from validation. A language model can propose a classification, transformation or recommended action. If correctness can be checked mechanically, record an independent rule result. For code modernization this might mean parsing, compilation or carefully scoped equivalence tests. For a form-based workflow it might mean schema validation, referential checks or allowed-value constraints. Neither replaces a domain-level evaluation of safety or rights impacts when applicable.
Design for negative outcomes. A failed validation is a first-class event. Specify whether it blocks, retries, escalates or requires human approval. Track the exact artifact reviewed; otherwise a reviewer may authorize one version while the system executes another. Ensure failed or timed-out downstream writes do not become apparent success states because a model described them confidently.
Make oversight usable. When Article 14 or another applicable duty requires human oversight, the interface must support real intervention appropriate to the system's risks and context. Show relevant limitations and anomalies, allow justified override and safe interruption, and retain a narrowly scoped record of consequential decisions. Do not confuse human-in-the-loop theater with a reviewer empowered to challenge the system.
Retain proportionately. For covered high-risk cases, Articles 19 and 26 include qualified six-month minimums for automatically generated logs under a party's control. The exact implementation must also account for the intended purpose and applicable other law, particularly personal-data rules. The proposed event schema uses references, not default raw prompt replication. An organizational retention schedule should identify record type, controller, access, expiry and deletion mechanism.
Verify the outcome. Successful API submission, a generated confirmation sentence and a committed downstream change are three different facts. Evidence should distinguish them. For example, log the outgoing request ID, authorization/validation gate result and returned durable system receipt. Where relevant, query the final state through an independent read.
Test the control chain. Create synthetic cases for a clean path, a malformed input, a failed deterministic check, a reviewer rejection, a tool timeout and a missing outcome receipt. For each, examine whether an investigator can identify the causal sequence without privileged access to unrelated private data. Measure completeness and timing in a test environment if appropriate—but publish no fabricated performance percentages.
Version the mapping. Regulations change and so do workflows. Record which legislative version, Article 50 guidance, model configuration and operational rule set a mapping used. Have qualified counsel decide legal applicability. The Evidence Map simply creates a useful engineering handoff between governance requirements and observable execution.
For AI-native modernization, that handoff prevents a common category error. Syntax-converted code is not a validated business transformation, and a successful assistant response is not verified enterprise execution. A robust workflow makes failed checks visible, routes consequential cases to people and links the approved artifact to what actually happened.
Primary references and reusable assets
- EU AI Act implementation timeline
- Article 12: record-keeping
- Article 14: human oversight
- Article 26: deployer obligations
- Ariftly AI Workflow Evidence Map on GitHub
Originally published with methodology, limitations, and the dated timeline at Ariftly.
Top comments (0)