What operational controls does the EU AI Act require for an AI workflow?
The AI Act applies obligations by system type, role and effective date. Article 50 transparency obligations generally apply from August 2026; amended high-risk rules follow later milestones. Ariftly's seven-stage evidence map offers a practical engineering method for linking AI workflow events to checks, oversight, exceptions and records—without claiming that its schema is legally mandated.
An AI Act checklist must begin with applicability
Imagine an enterprise workflow that ingests a business document, asks an AI system to interpret it, checks its output, routes anomalies to a person and writes a result to another system. Failure can occur at several points: wrong input, implausible interpretation, incomplete validation, an unreviewed exception or a downstream write that never happened. A generic statement that human oversight exists does not show which step failed or whether the final outcome occurred.
Begin with a workflow inventory, not a model inventory alone. For each use, record the intended purpose, the party placing or putting the system into service, the party operating it under authority, affected people and actual downstream actions. A useful intake has five gates: territorial scope, legal actor, risk or use category, application date and interaction with other law. An organization may be a deployer in one workflow and a provider in another; Article 27 applies only to specified deployers and uses, not every enterprise AI workflow.
The implementation calendar is not one date
The European Commission's current implementation timeline incorporates the July 2026 Digital Omnibus amendments. The milestones below describe when identified provisions apply; they are not statistics about how many organizations are ready or compliant. Exact transitions and exceptions still require use-specific review.
| Milestone | Date | Workflow-team implication |
|---|---|---|
| AI Act entered into force | 1 August 2024 | Use the current consolidated text, not an old synopsis |
| General provisions and prohibitions apply | 2 February 2025 | Screen relevant definitions and prohibited practices |
| GPAI model and governance provisions apply | 2 August 2025 | Determine whether GPAI-provider duties are relevant |
| Article 50 transparency generally applies | 2 August 2026 | Assess interaction- and content-specific notices or marking |
| Limited Article 50(2) transition ends | 2 December 2026 | Check eligibility; this is not a blanket transparency deferral |
| Annex III high-risk rules apply | 2 December 2027 | Prepare use-case-specific controls subject to applicable provisions |
| Annex I product-related high-risk rules apply | 2 August 2028 | Coordinate system and regulated-product requirements |
Logs, retention and human oversight are different controls
Logging capability is not the same as retaining every business artifact. Article 12 addresses automatic recording of relevant events in high-risk AI systems for traceability and monitoring purposes. An enterprise may additionally record validation checks or downstream receipts, but that broader evidence record is an engineering choice rather than a verbatim Article 12 schema.
Six months is a qualified minimum, not a universal rule for every AI conversation. Articles 19(1) and 26(6) address automatically generated logs under the control of providers or deployers of covered high-risk systems for a period appropriate to the intended purpose and at least six months, unless other applicable law provides otherwise, particularly personal-data law.
Human oversight also requires a usable intervention path. Article 14 addresses risk-proportionate abilities to understand limitations, recognize automation bias, interpret outputs, override or disregard results and interrupt operation safely. Article 26 assigns deployer responsibilities for competent oversight and monitoring. A nominal approval button does not prove that a reviewer had the information, authority or time to decide.
The Ariftly AI Workflow Evidence Map
Ariftly proposes an implementation framework, not a new legal standard. It follows seven stages and asks which control was applied and what evidence a team could later inspect. Each mapping should be labelled as a conditional legal requirement, a suggested implementation of that requirement or voluntary engineering assurance. A legal anchor is not a determination that the provision applies to a particular workflow.
| Workflow stage | Core engineering question | Example evidence |
|---|---|---|
| 1. Input | Did this run use a permitted, identified input? | Source/version pointer and provenance check |
| 2. AI action | What system attempted what operation? | System version, action reference and event time |
| 3. Validation | Which independent checks ran and with what result? | Rule version and pass/fail outcomes |
| 4. Human oversight | Who could intervene, and what decision was made? | Reviewer role, decision, reason and time |
| 5. Exception | Was a failed control halted, retried or escalated? | Case ID and stop or escalation event |
| 6. Outcome | Did the downstream system reach the required state? | Receipt or independently checked state |
| 7. Evidence record | Are the links inspectable and retained appropriately? | Event manifest, access policy and retention schedule |
From policy statement to reconstructable execution
Consider a synthetic modernization example: an AI system proposes a mapping from Oracle SQL to Snowflake SQL. An engineering run can retain a source reference, output artifact reference, parser or compiler validation, test results, any required review and the eventual approved artifact. If generated SQL looks correct but fails a deterministic check, the run is validation failed—not completed. If deployment is outside the experiment's scope, the record should say not performed rather than imply production adoption.
The proposed event record has twelve named fields: run ID, event ID, time, stage, system version, input-provenance reference, action or rule reference, validation result, human-decision reference, exception reference, verified-outcome reference and retention-policy ID. That count describes an authored schema, not an EU requirement or empirically proven minimum. Sensitive data should be referenced and access-controlled instead of copied indiscriminately.
A provider–deployer split changes the controls
A provider building or placing an in-scope high-risk system on the market must examine provider duties such as compliant design, documentation, information for deployers, logging and relevant conformity processes. A deployer operating a system under its authority must examine instructions, assigned oversight, controlled input data, operation monitoring, reportable issues and logs under its control. The legal role can depend on facts beyond procurement paperwork.
Evidence responsibility should therefore be divided deliberately. A provider may make structured logs technically available and document their meaning; a deployer may configure access, supervision, monitoring and retention where applicable. A log format cannot compensate for a missing oversight process, and a written oversight policy cannot reconstruct an unrecorded failure.
| Actor | Operational focus | Candidate evidence |
|---|---|---|
| Provider | System design, documentation, deployer information and technical logging | Versioned documentation, log specification and control-test records |
| Deployer | Instructions, input control, oversight, monitoring, incidents and controlled logs | Configured access, assigned reviewers, monitoring events and retention record |
Transparency is a separate workflow branch
Article 50 obligations are triggered by particular kinds of AI interaction or AI-generated or manipulated content. Depending on the system, role and exceptions, they can concern informing people of AI interaction, marking synthetic outputs and disclosing certain deepfakes or public-interest text. For an affected workflow, record which rule was assessed, what notice or marking mechanism applied, the relevant content or interaction version and how it was tested.
Article 50 generally applies from 2 August 2026. The Commission describes a narrow transition until 2 December 2026 for certain systems placed on the market earlier and subject to Article 50(2) marking and detection duties. That allowance does not suspend every transparency obligation, and a user-facing banner should not be assumed necessary for every backend operation.
A practical engineering acceptance test
Run one normal case and at least one deliberately induced failure through a single AI-enabled workflow. Passing supports an engineering claim about traceability in the tested case. It does not by itself establish legal compliance, real-world safety or performance across unseen inputs.
- Identify the input source and the applicable workflow version.
- Record the system and action version without treating model confidence as validation.
- Confirm that an independent failed check blocks a consequential action.
- Give an authorized person enough information and authority to override or stop where applicable.
- Verify the resulting action through a downstream receipt or checked state.
- Reconstruct the run without exposing unnecessary personal data.
Ariftly View: from human-operated to AI-operated
Start with the workflow, not the model. In a human-operated process, people interpret inputs, make decisions and execute updates while evidence may be scattered across tickets and systems. An AI-assisted process drafts or explains while a person acts. Bounded AI execution can perform well-specified steps after deterministic checks and escalate consequential exceptions. A more AI-operated workflow should expand authorized scope only when measured reliability and review systems support it.
The goal is not to eliminate people. It is to move human attention from repetitive interpretation toward disputed cases, risk decisions and exceptions. The evidence chain should become stronger as delegated action expands. Less duplicated checking, fewer false-success states and better exception preparation are design objectives—not independently measured Ariftly outcomes.
How Ariftly would operationalize this workflow
Ariftly Forge is the visible, in-development Record–Redesign–Operate workflow transformation experience. As an engineering direction, Record could identify the workflow and its evidence breaks; Redesign could place validation and escalation gates; Operate could connect bounded execution to checks and evidence records. Forward-Deployed AI Engineering describes the implementation motion that adapts workflow design to specific enterprise systems and responsibilities.
This is directional. It is not a claim that an AI Act compliance product, production runtime, certification or customer deployment is available. Ariftly's initial AI-Native Modernization focus and local synthetic Oracle-to-Snowflake V1 illustrate why semantic validation and verified outcomes matter; they are not compliance or production proof.
Methodology, limitations and update policy
This article maps selected provisions from the EU AI Act text consolidated on 27 July 2026 and current European Commission guidance to proposed operational control points. Primary claims and dates were rechecked on 21 October 2026. The article does not estimate compliance rates, audit an organization or substitute for legal advice. The seven stages and twelve fields are author-created categories.
Dates can change through amendments, while legal role, classification, exceptions, privacy retention and sector duties remain use-specific. Ariftly will date material legal reviews and version changes to the original framework. Readers applying the map should recheck the current consolidated law and obtain qualified advice for their facts.
Suggested citation: Ariftly (2026), Ariftly AI Workflow Evidence Map, v1.0. The original framework and downloadable data are available under CC BY 4.0; EU legal text and third-party materials retain their own terms.