What finance teams can build with the AI Act's extra sixteen months.
The heaviest obligations in the EU AI Act now land on 2 December 2027 rather than this August. For finance functions, that is a well-timed window: enough room to find out what AI is actually running inside the ERP, decide what is in scope, and build the oversight and evidence that make the answer defensible.
Thesis
Sixteen months is enough time to build governance that outlasts the deadline.
The Digital Omnibus on AI moved the stand-alone high-risk obligations from 2 August 2026 to 2 December 2027. Measured from the original date, that is sixteen additional months. It is the difference between assembling a compliance position under pressure and designing one that a controller would actually want to operate.
The work that fills that window is not primarily legal. It is an inventory problem, a scope problem, and an evidence problem, and all three are familiar territory for a finance function. Knowing which systems touch which processes, deciding which rules apply, and being able to show later why a decision was reasonable is the ordinary shape of a control environment.
There is a second reason to start now. The obligations that already apply did not move, and one of them arrives in weeks. Doing the inventory once serves the near-term transparency position and the 2027 high-risk position together.
Where the rules stand, and why operators should care.
The deferral is now law-in-progress, and the Commission has published it
The Commission proposed the Digital Omnibus on AI on 19 November 2025. Negotiators reached provisional agreement on 7 May 2026, the European Parliament endorsed it on 16 June 2026, and the Council gave its final green light on 29 June 2026. The Commission’s own AI Act timeline now shows the revised dates.
Planning can proceed against the new dates rather than against rumour. The formal publication step completes the process, so treat the schedule as settled while confirming the final text before relying on any single clause.
Stand-alone high-risk obligations moved to 2 December 2027
Obligations for high-risk AI systems listed in Annex III were postponed from 2 August 2026 to 2 December 2027. Systems embedded in products already covered by EU product safety legislation under Annex I moved from 2 August 2027 to 2 August 2028.
That is sixteen months of additional runway measured from the original date. It is enough to build a governance substrate deliberately, which is a materially better position than the compressed timetable that applied at the start of the year.
The 2 August 2026 date did not disappear
The Article 50 transparency obligations were not deferred. They still take effect on 2 August 2026, binding both providers and deployers of the systems they cover.
Something is still due in a matter of weeks. The useful part is that meeting it requires knowing which AI systems are in use and what each one produces, which is the same inventory the high-risk regime will later ask for.
Three sets of obligations have already been live for some time
The Article 5 prohibitions and the Article 4 AI literacy duty have applied since 2 February 2025. The general-purpose AI model obligations in Articles 51 to 56 have applied since 2 August 2025.
For most finance functions the live obligation today is AI literacy, not high-risk conformity. It is also the cheapest one to satisfy properly, and it is the foundation the human-oversight duty later depends on.
Credit scoring of individuals is the finance-adjacent high-risk entry
Annex III point 5(b) covers “AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud”.
The scope test is narrower than most finance teams assume. It turns on natural persons and on creditworthiness, and it carves fraud detection out explicitly.
Most AI inside a finance function sits outside Annex III
Invoice coding, cash application, close task automation, variance explanation, spend classification, forecasting, and anomaly detection are not creditworthiness assessments of natural persons and are not listed elsewhere in Annex III.
This is the finding that changes the workload. The correct output of a scoping exercise is usually a short in-scope list and a long, documented out-of-scope list, not a blanket programme applied to everything.
Finance is nearly always a deployer, not a provider
Article 26 places obligations on deployers: assign human oversight to competent, trained staff with authority to act; keep input data relevant and representative where the deployer controls it; monitor operation and report serious incidents; and retain system logs.
Deployer duties are operational rather than engineering duties. They map onto segregation of duties, review evidence, and retention policies that a finance function already runs for other purposes.
The log-retention duty is stated as a floor
Article 26 requires deployers to keep logs automatically generated by the high-risk AI system “for a period appropriate to the intended purpose…of at least six months”.
Six months is shorter than a statutory audit cycle. A finance team that aligns AI log retention with its existing ledger and evidence retention clears the regulatory floor comfortably and gets a more useful audit trail.
Run the scope test before building the programme.
The single most useful hour in this work is spent reading Annex III against a real list of systems. Point 5(b) reaches AI intended to evaluate the creditworthiness of natural persons or establish their credit score, and it expressly excludes systems used to detect financial fraud. Both halves of that sentence matter.
Applied honestly, it puts most finance AI outside the high-risk regime. A model that codes invoices, matches remittances to open items, proposes accruals, classifies spend, or flags an unusual payment is not assessing whether a person is creditworthy. A business-to-business credit limit review on corporate counterparties is not assessing a natural person either.
The exceptions are worth finding deliberately. Credit assessment of sole traders and individual customers, and any consumer lending or instalment offering run out of the order-to-cash process, are the places where a finance system can genuinely land in Annex III. Those are the systems that deserve the full deployer control set.
Record the negative conclusions with their reasoning. An out-of-scope determination that nobody wrote down is indistinguishable, a year later, from a scope question nobody asked.
AI system inventory
Keep one governed register of every AI system touching a finance process, including features embedded in the ERP and in third-party modules, rather than a survey rebuilt whenever someone asks.
Evidence to retain
System ID, business process, vendor, model or feature name, version, deployment date, owner, provider-or-deployer role, Annex III assessment, assessment date, approver.
Role classification per system
Record whether the organisation acts as provider or deployer for each system, since the obligation set differs sharply and fine-tuning or re-purposing a system can change the answer.
Evidence to retain
System ID, role, basis for the classification, whether the system was modified or re-purposed, substantial-modification review date, legal sign-off reference.
Scope determination and its reasoning
Store the Annex III scope conclusion with the reasoning that produced it, especially for out-of-scope calls. An undocumented negative is the hardest position to defend later.
Evidence to retain
System ID, Annex III point tested, natural-persons test result, fraud-detection exception applied, conclusion, reviewer, date, supporting note.
Data Model
Give the AI inventory a home in the system of record.
The register that matters is not a list of vendors. It is a list of systems mapped to the finance processes they touch, with an owner, a role classification, and a scope conclusion attached to each one. Held that way, it answers the transparency question this August and the high-risk question in 2027 from the same source.
Stamping is the other structural decision. Where an AI system contributed to a posting, a classification, or an estimate, the resulting record should carry the system and version that produced it. That single field is what later allows a population to be identified, sampled, and re-reviewed without reconstructing history.
Retention should be set against the longest applicable requirement rather than the regulatory floor. Article 26 asks for at least six months. Financial records generally live far longer, and aligning the two costs little while producing a much more useful audit trail.
Human oversight assignment
Name the people who oversee each system, and record that they have the competence, training, and authority Article 26 requires, rather than leaving oversight implied by a job title.
Evidence to retain
System ID, named overseer, deputy, competence basis, training completed, authority to override or halt, effective from, effective to.
Model and version stamping on financial output
Where an AI system contributes to a posting, a classification, or an estimate, stamp the resulting record with the system and version that produced it, so the population can be identified later.
Evidence to retain
Journal or document reference, system ID, model version, confidence or score, human review flag, reviewer, override reason, timestamp.
Log and evidence retention
Set AI log retention against the longest applicable requirement rather than the six-month floor, and store logs where the audit process can actually reach them.
Evidence to retain
System ID, log location, retention period, retention basis, access control, integrity control, disposal date, legal-hold flag.
Deployer duties are control duties.
Article 26 reads more like an internal control standard than a technology standard. It asks for named human oversight by people with competence, training, authority, and support; for input data that is relevant and sufficiently representative where the deployer controls it; for monitoring and prompt reporting of serious incidents; and for retained logs. A finance function that already operates preparer and reviewer roles, exception reporting, and record retention has most of the machinery.
Human oversight is the duty most often satisfied on paper and not in practice. The test worth applying internally is simple: can the named overseer stop the system, has that authority been written down, and is there evidence of it being exercised. An oversight role that has never altered an outcome invites the question of whether it exists.
The workplace notification duty is easy to overlook and cheap to satisfy. Where a high-risk system is deployed at work, workers representatives and affected workers must be informed before it is put into use, following the applicable procedures.
None of this needs to wait for December 2027. Running these controls through a full audit cycle first is how a team discovers which parts are workable, at a point where adjusting them carries no regulatory consequence.
Implementation checklist
1. Inventory before you classify
List every AI system touching finance, including ERP-embedded features that arrived through a release rather than a procurement. Most programmes stall because the population was never fixed, not because the rules were unclear.
2. Run the Annex III test and write down the negatives
For each system, test it against Annex III and record the conclusion with its reasoning. Expect most finance systems to fall outside, and treat the documented out-of-scope decision as the deliverable.
3. Settle the Article 50 position before 2 August 2026
Transparency obligations were not deferred. Identify anything that interacts directly with people or generates content, and get the disclosure position agreed while the scope work is already open.
4. Close the AI literacy gap that is already live
The Article 4 duty has applied since 2 February 2025 and reaches staff and others operating AI on the organisation’s behalf. Targeted training for the teams actually using these systems satisfies it and improves the output.
5. Stand up deployer controls on the in-scope few
Name overseers with real authority, define what an override looks like, and start retaining logs now. Running these controls for a year before they are required is how you find out whether they work.
6. Stamp AI-assisted output at the point of posting
Add system and version identifiers to records an AI system helped produce. This is the cheapest change to make early and the most expensive to retrofit across a year of closed periods.
Constructive failure modes to design around.
The extra time is read as a pause
Treat the deferral as a build window with a fixed end. The obligations that already apply did not move, and the systems in scope on 2 December 2027 will mostly be systems deployed well before then.
Scope is assumed rather than tested
Run the Annex III test explicitly. Assuming a finance model is high-risk creates unnecessary work; assuming it is not, without recording why, leaves an undefended position in front of an auditor.
The inventory misses what arrived in a release
Sweep ERP and vendor release notes as an inventory source. AI features increasingly appear inside systems already owned, without a procurement event to trigger a review.
Human oversight is nominal
Give overseers the authority to halt or override, and evidence that they used it where appropriate. Oversight that has never changed an outcome is difficult to distinguish from no oversight.
Logs exist but are unreachable
Confirm the audit team can retrieve logs for a named period without a vendor ticket. A retention policy that cannot be exercised on request is not evidence.
Provider status is acquired by accident
Review whether fine-tuning, re-purposing, or placing a system on the market under your own name changes your role. The obligation set for providers is substantially heavier than for deployers.
API and event-design considerations.
An AI governance layer inside finance should expose events such as ai_system.registered, scope.assessed, role.classified, oversight.assigned, output.stamped, override.recorded, and incident.reported.
Each event should carry system ID, model version, business process, actor, timestamp, and an idempotency key. The case worth designing for explicitly is the version change: a vendor updating a model mid-period can alter behaviour across a population of postings that has already been reviewed, and the only way to bound that later is to have stamped the version at the time.
The output is a small governance sub-ledger sitting beside the financial one, recording which system produced what, who oversaw it, and what was retained. That is the artefact that turns an AI Act question into a query rather than a project.
Example AI governance evidence payload
{
"ai_system_id": "fin_ai_00147",
"business_process": "customer_credit_limit_review",
"vendor": "erp_core",
"model_version": "credit-assist-3.2",
"role": "deployer",
"scope_assessment": {
"annex_iii_point_tested": "5(b)",
"counterparty_type": "legal_person_only",
"natural_persons_in_scope": false,
"fraud_detection_exception_applied": false,
"conclusion": "out_of_scope",
"reasoning_ref": "scope_note_2026_07",
"reviewer": "head_of_internal_audit",
"reviewed_on": "2026-07-23"
},
"human_oversight": {
"named_overseer": "credit_manager",
"authority_to_override": true,
"overrides_last_quarter": 14,
"training_completed_on": "2026-03-11"
},
"logging": {
"logs_retained": true,
"retention_months": 84,
"retention_basis": "aligned_to_statutory_records",
"exportable_by_customer": true
},
"output_stamping": {
"stamps_journal_records": true,
"fields": ["system_id", "model_version", "confidence", "human_review_flag"]
}
}Questions CFOs and controllers should ask ERP and AI vendors.
Practical Takeaway
Build the inventory once and let three deadlines draw on it.
The near-term work is well bounded: inventory every AI system touching finance, test each one against Annex III and write down the reasoning, settle the transparency position before 2 August 2026, close the AI literacy gap that has been live since February 2025, and begin stamping AI-assisted output at the point of posting. None of that requires a system replacement, and all of it is cheaper than retrofitting a year of closed periods.
For ERP buyers, this is a clean architecture test. A platform that can name the model behind a proposed posting, expose its logs without a support request, and capture human override as structured data will absorb the 2027 obligations as configuration. One that treats AI as an opaque convenience feature will push that work back onto the finance team, every period, with no offsetting benefit.
Sources
- European Commission: Regulatory framework for AI, including the application timeline
- Council of the EU: Artificial intelligence, Council gives final green light to simplify and streamline rules (29 June 2026)
- AI Act, Annex III: high-risk AI systems referred to in Article 6(2)
- AI Act, Article 4: AI literacy
- AI Act, Article 26: obligations of deployers of high-risk AI systems
- AI Act, Article 50: transparency obligations for providers and deployers
- Gibson Dunn: EU AI Act Omnibus agreement, postponed high-risk deadlines and other key changes
- IAPP: AI Act Omnibus, what just happened and what comes next