A proposed deadline change won’t tell you whether an AI-assisted approval used stale evidence, reached the wrong approver, or exceeded its authority. Those kinds of failures can affect production decisions now.
On May 7, the Council presidency and European Parliament negotiators reached a provisional agreement to change when parts of the EU AI Act would apply. The proposed dates are December 2, 2027, for stand-alone high-risk AI systems and August 2, 2028, for high-risk AI systems embedded in regulated products. As of this article’s May 12 publication date, the agreement still needs endorsement and formal adoption. The existing application dates remain in force. (European Parliament, May 7, 2026)
This creates uncertainty for legal planning. For engineering leaders, the immediate question is, can each production workflow make a consequential decision within defined evidence, policy, and authority boundaries?
The Agreement Changes Timing, Not Exposure
Regulatory milestones and operational exposure run on different clocks. Once a system’s output informs or triggers an action, its consequences don’t wait for a compliance date.
The AI Act’s original text reflects that operational character, where its requirements for high-risk systems include a lifecycle risk-management process, automatic event logging, human oversight, and standards for accuracy and cybersecurity. (Regulation (EU) 2024/1689, Articles 9-15) The law assigns particular duties according to an organization’s role and the system’s classification, so counsel should confirm how those duties apply. But the engineering value of those controls isn’t confined to regulated systems.
Consider an AI-assisted workflow that recommends whether to approve privileged access to a production service. The recommendation may be reasonable while the workflow still fails because it relied on stale evidence, routed approval to someone without the right authority, or invoked a tool with broader permissions than the decision allowed. Deadline changes don’t alter those failure modes.
A Policy Document Can’t Operate The Workflow
Inventories, risk classifications, and policy documents are necessary inputs. Those don’t enforce a decision at runtime, and a policy should require human review. The live workflow still has to identify who qualifies as the reviewer, present the underlying evidence, record the approval, and stop if nobody responds.
Operational control requires the workflow to connect five elements:
- Evidence: Which sources support this decision, and are they authoritative, current, and complete enough for its consequence?
- Policy: Which rule, threshold, or constraint permits the next step?
- Authority: Who or what may recommend, approve, execute, or stop the action?
- Action: What did the system do, in which environment, and through which identity?
- Outcome: What happened next, and can the action be contained, reversed, or corrected?
Evodant calls the engineering of this path Decision Engineering. It treats the operational decision as the unit of design. The components of such a system include the model, identity, source data, policy evaluation, tool permissions, human approval, observability, and recovery.
A model card can describe intended behavior, and a control matrix can assign responsibility. Neither can show that a specific production decision used the right source, passed the current policy, received valid approval, and stayed within its action boundary. For that, the workflow needs to capture a decision record while it runs.
Start With One Decision Boundary
An enterprise-wide control program can spend months cataloging systems without changing the behavior of one live workflow. It’s best to pick a consequential decision with a named owner and a measurable outcome, then define its boundary.
Name The Decision And Its Consequence
Write the decision as an action, not a capability. “Approve a service exception” is clearer than “use AI for service operations.” Identify who bears the consequence if the decision is wrong, late, or unsupported.
Set Evidence Requirements
List the sources the workflow may use. Define acceptable provenance, freshness, quality, and conflict handling. If required evidence is missing or stale, the workflow should stop or escalate rather than improvise.
Separate Recommendation From Authority
Specify whether the system supports a person, recommends a bounded choice, or executes an action. Access to a tool isn’t authority to use it in every case. Bind permissions to the decision, policy state, user or service identity, and approved scope.
Define Stop And Recovery Conditions
State what happens when confidence is low, sources disagree, an approver is unavailable, a dependency fails, or an action returns an unexpected result. Recovery isn’t a generic rollback statement. It needs an owner, a tested procedure, and enough telemetry to determine what changed.
Capture A Decision Record
Record the evidence references, policy version, model and configuration, identity, approval, action, and observed outcome. Keep the record proportionate to the decision and applicable retention rules. The aim is to reconstruct why the workflow acted, not to collect data without limit.
Test The Controls Under Representative Conditions
A control review shouldn’t end when each required control appears in an architecture diagram. Teams need to test whether the full decision path behaves as intended under conditions resembling production.
Build an evaluation set from routine cases, hard cases, and known exceptions. Feed it stale and conflicting evidence. Change the model or prompt version. Remove an integration, make an approver unavailable, and attempt an action outside the permitted scope. Then observe whether the workflow proceeds, asks, escalates, refuses, or recovers as designed.
Measure the operating result as well as model quality. Useful measures may include unsupported-decision rate, escalation rate, approval delay, cost per completed case, policy exception volume, and recovery time. Select measures that expose the consequence and constraints of the chosen decision. A single average accuracy score can’t answer whether the workflow stayed within authority.
Representative evaluation also helps set the right automation level. Keep decision support when a person must interpret contested evidence. Use decision augmentation when the system can make a bounded recommendation but an authorized person must decide. Permit bounded automation only when the action, evidence threshold, permission, monitoring, and recovery path are explicit.
Use The Additional Time To Produce Operating Evidence
If the provisional agreement becomes law, the additional time should produce operating evidence, not another control inventory. Select one consequential workflow and test whether its evidence rules, authority boundaries, stop conditions, and recovery procedure work under representative conditions.
The resulting decision records can support legal readiness while answering a more immediate management question: can the organization explain, defend, and improve how this system makes decisions today?
The proposed delay isn’t a reason to accelerate every AI use case, either. It creates room to narrow scope, fix weak boundaries, and test what happens when the workflow can’t proceed normally. A smaller governed workflow is more useful than a broad deployment whose decisions can’t be reconstructed.
These questions become engineering work when their answers reside in different systems and teams. Evidence freshness, approval authority, tool permissions, and recovery conditions have to agree while the workflow is running; a checklist can’t enforce that agreement.
Turning AI Act controls into operating controls? Book a Consultation.