EU AI Act high-risk rules, 2 December 2027: hiring and credit AI agents

Summary. The delay is law. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was signed on 8 July 2026, published in the Official Journal on 24 July and has been in force since 27 July 2026. It moved the EU AI Act's rules for Annex III high-risk systems from 2 August 2026 to 2 December 2027, and those for high-risk AI in regulated products to 2 August 2028. Annex III point 4 covers AI that recruits, filters, ranks or evaluates candidates and manages workers; point 5(b) covers AI that assesses creditworthiness or sets credit scores, with fraud detection excluded. A system that profiles people is always high-risk. From 2 December 2027, providers of new hiring and credit agents need risk management, data governance, automatic logs, human oversight, security controls, a quality management system, a self-assessed conformity check, CE marking and EU database registration before launch. Deployers keep logs for at least six months, assign trained overseers, inform workers and applicants and, for credit, complete a fundamental rights impact assessment. Fines reach EUR 15 million or 3% of worldwide turnover. EN 18286:2026, the first harmonised standard, covers the quality management system.

About this article. For product, engineering and compliance leads who build or buy AI agents for hiring, worker management or consumer credit in the EU. On 7 November 2026 we checked every date, article and threshold against the Official Journal texts of Regulation (EU) 2024/1689 and Regulation (EU) 2026/1744 as published on 12 July 2024 and 24 July 2026 (Publications Office copies), the Commission's AI Act pages, the AI Act Service Desk and Implementing Decision (EU) 2026/2274. This is general information, not legal advice; the Commission's classification guidelines are still in draft, so confirm classification with qualified EU counsel. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

Adopted law: the status on 7 November 2026

The Commission proposed the AI Omnibus on 19 November 2025, and Parliament and Council reached political agreement on 7 May 2026. Parliament voted on 16 June 2026, the Council approved it on 29 June, and the act was signed on 8 July, published on 24 July and in force from 27 July 2026. Our Digital Omnibus explainer covers the full package.

Two points matter for planning. The proposal tied the start date to the availability of standards, with a 16-month backstop. The final Article 113 drops that trigger and fixes the dates. And amended Article 111(2) catches high-risk systems already on the market before 2 December 2027 only if their design changes significantly from then on; systems meant for public authorities must comply by 2 August 2030 regardless. The recitals add that the grace period works per type and model: if one unit was lawfully on the market before the date, identical units can follow while the design stays unchanged.

The dates below come from the AI Act Service Desk timeline and Articles 111 and 113 as amended.

Which hiring and credit agents are high-risk

The Omnibus did not touch Annex III. Point 4(a) covers AI meant for recruiting or selecting people, including placing targeted job adverts, analysing and filtering applications, and evaluating candidates. Point 4(b) covers decisions on terms of work, promotion and termination, task allocation based on behaviour or personal traits, and monitoring or evaluating performance. Point 5(b) covers AI that evaluates the creditworthiness of individuals or sets their credit score, except AI used to detect financial fraud. Point 5(c), risk assessment and pricing for life and health insurance, often sits in the same product.

The Article 6(3) filter. An Annex III system is not high-risk if it poses no significant risk of harm, including by not materially influencing the decision, and it only performs a narrow procedural task, improves the result of a completed human activity, detects patterns or deviations in earlier decisions without replacing human review, or performs a preparatory task. The filter has a hard stop: a system that profiles people is always high-risk. A provider relying on the filter must document its assessment before launch and still register the system in the EU database under Article 49(2). The Omnibus kept that registration but trimmed it: Annex VIII, Section B no longer asks for a summary of the grounds or the list of Member States.

The Commission's draft classification guidelines, published on 19 May 2026 with feedback open until 23 July 2026, were still marked as draft when we checked; the Commission says it will adopt the final version by the end of 2026. Their worked examples map well onto agent features.

Agents change their intended purpose quickly. A general assistant that a customer configures to rank applicants has a new intended purpose. Under Article 25(1)(c), a deployer, distributor or other third party that changes the intended purpose of a system so that it becomes high-risk is treated as its provider. The Omnibus added two duties. The original provider must give the new provider documentation, known failure modes and test access, unless it stated clearly that its system must not be made high-risk. And a provider must agree in writing with suppliers of models, tools and components the information and access it needs; breaches of either duty fall in the EUR 15 million tier. If you sell an agent platform, decide in contract who is the provider, and either support the high-risk use with the controls below or exclude it in writing.

What providers must build: Articles 9 to 17 for an agent stack

The Commission lists the provider duties as risk mitigation, high-quality datasets, activity logging, detailed documentation, information to deployers, human oversight, and robustness, cybersecurity and accuracy. Here is what each means for an LLM agent with tools, retrieval and a workflow engine.

Risk management (Article 9). Agents fail in ways a static model does not: a tool returns stale data, retrieval pulls the wrong policy, a model upgrade shifts outputs. Treat each as a hazard with an owner, a test and a threshold, and include foreseeable misuse, such as recruiters asking the agent to filter for cultural fit.

Data governance (Article 10). Data sets must be relevant, sufficiently representative and, as far as possible, free of errors and complete, and providers must examine them for bias and take measures to detect, prevent and mitigate it. Where a system does not train models at all, Article 10(6) applies those criteria only to testing data sets. Whether retrieval corpora count is unsettled; manage them under Article 9 either way. The Omnibus moved the legal basis for using special categories of personal data for bias work into a new Article 4a, with conditions: strictly necessary, no workable synthetic or anonymised alternative, pseudonymisation, access controls, no onward transfer, and deletion once the bias is corrected. It creates no bias duty for other systems, but high-risk providers already carry one under Article 10.

Logging (Articles 12, 19 and 26). Logs must make the system's operation traceable and support post-market monitoring. Providers keep the logs under their control for at least six months, and deployers do the same under Article 26(6), unless other law sets a different period. A single LLM call log is not enough; you need a run-level trace linking each decision to every step. Our LLM observability comparison covers tools that capture part of this trail.

Human oversight (Article 14). The overseer must be able to understand the system's capacities and limits, stay alert to automation bias, interpret the output correctly, decide not to use it or override it, and halt the system with a stop control. For agents, that means an approval gate before any adverse action, such as rejecting a candidate or declining a loan, a view of the evidence used, and a kill switch that halts queued actions.

Cybersecurity (Article 15). The Act names data poisoning, model poisoning, adversarial examples and model evasion, confidentiality attacks and model flaws. Prompt injection hidden in a CV or bank statement is the obvious agent case. A new Article 42(3) deems a system that meets the Cyber Resilience Act's essential requirements to meet Article 15 on cybersecurity. Our guide to AI agent guardrails, tools and costs compares the control layers.

Quality management (Article 17). This is where the first harmonised standard helps. Implementing Decision (EU) 2026/2274 of 12 October 2026 published the reference of EN 18286:2026 in the Official Journal on 14 October, and the presumption of conformity runs from that date. The Commission announced it on 19 October; the standard follows the AI system lifecycle and is designed to sit on top of ISO/IEC 42001, ISO 9001 or a sectoral QMS. It is still the only AI Act standard referenced, so the other requirements have no presumption route yet.

Foundation model inputs. If your agent runs on a third-party GPAI model, Article 53 entitles you to the Annex XII information you need for your own technical file. Our guide to the 2 August 2027 GPAI deadline for legacy models lists what to ask for.

Conformity assessment, CE marking and registration

For Annex III points 2 to 8, which include hiring and credit, Article 43(2) sets the internal-control procedure in Annex VI. No notified body is involved: the provider checks its QMS against Article 17 and its technical documentation against the requirements. Biometric systems under point 1 can need a notified body, so adding face or voice analysis to interviews changes the route.

After a successful assessment the provider draws up an EU declaration of conformity (Article 47), affixes the CE marking (Article 48), digitally for software, and registers itself and the system in the EU database under Article 49(1) before placing it on the market. Under Article 18, the documentation and declaration stay at the authorities' disposal for 10 years after the system is placed on the market. Providers outside the EU appoint an EU authorised representative by written mandate. Providers also run post-market monitoring (Article 72) and report serious incidents within 15 days at most (Article 73).

What counts as a significant change? For agents, this is the open question. Article 111(2) spares systems already on the market until their design changes significantly, and Article 43(4) requires a new assessment after a substantial modification. Agent teams swap models, rewrite prompts and add tools monthly. Define in your QMS which changes trigger re-assessment, pre-declare planned changes in the technical documentation, and record the reasoning. As we read it, relying on the grace period while shipping weekly releases is a weak position.

What deployers must do: employers and lenders

The employer or lender using the system is the deployer, with its own duties under Article 26:

• Use as instructed and assign human oversight to people with the competence, training, authority and support to exercise it.

• Control input data where you supply it, so it is relevant and sufficiently representative.

• Monitor operation, suspend the system and inform the provider and market surveillance authority if it presents a risk, and report serious incidents. Financial institutions meet this through their financial-services governance rules.

• Keep logs under your control for at least six months; financial institutions keep them in their financial-services records.

• Tell workers. Before using a high-risk system at work, employers must inform workers' representatives and affected workers.

• Tell affected people. Deployers of Annex III systems that make or assist decisions about people must inform them.

• Feed the DPIA. Use the provider's Article 13 information for the GDPR data protection impact assessment.

Credit adds a fundamental rights impact assessment. Article 27 requires deployers of point 5(b) and 5(c) systems, as well as public-law bodies and private entities providing public services, to assess the impact on fundamental rights before first use. It covers the processes, frequency of use, affected groups, specific risks, oversight and remedies, and the results go to the market surveillance authority. The Omnibus lets deployers cross-refer to their DPIA and asks the AI Office for a questionnaire template. Private employers using a hiring agent are not on the list unless they provide public services.

Right to explanation. Under Article 86, a person significantly affected by a decision based on an Annex III system's output can ask the deployer for a clear explanation of the system's role and the main elements of the decision. Your traces must support a human-readable answer.

Worked example: oversight capacity and log storage for a credit agent

These figures are assumptions to show the arithmetic, not industry benchmarks.

A lender's credit agent handles 30,000 consumer applications a month, and every proposed decline goes to a human reviewer.

• Assumed decline rate 25%: 30,000 × 0.25 = 7,500 reviews a month.

• Assumed 6 minutes per review: 7,500 × 6 = 45,000 minutes = 750 reviewer hours.

• At 160 working hours per reviewer per month: 750 ÷ 160 = 4.69, so about 4.7 full-time reviewers before training and quality checks.

Now the logs. Each application run averages 12 recorded steps (retrieval, bureau call, scoring, explanation draft, reviewer action) at an assumed 8 KB per step.

• 30,000 × 12 × 8 KB = 2,880,000 KB, about 2.9 GB a month.

• Six-month minimum retention: 2.88 GB × 6 = 17.3 GB, before replicas and backups.

Storage is cheap; reviewer time is not. If reviewers rubber-stamp the agent to keep up, oversight fails Article 14 in practice. Size the team before go-live and track override rates.

How this fits with GDPR, California and India

The AI Act sits on top of the GDPR, not instead of it. Article 22 GDPR, the right not to be subject to solely automated decisions with legal or similarly significant effects, still applies, and Article 26(9) of the AI Act points deployers to the GDPR impact assessment. Teams selling into the US face California's ADMT rules: a business already using automated decisionmaking technology for significant decisions must comply by 1 January 2027. Our California ADMT guide for AI hiring and lending covers that regime of notices, opt-outs and access requests; the EU regime centres on product conformity before launch. One logging and oversight design can serve both.

Indian HR-tech and lending-tech vendors whose agents serve EU employers or lenders are providers placing systems on the EU market, wherever they are based. They need an EU authorised representative, the full provider file and registration. The logging and notice work overlaps with India's DPDP rules; our DPDP engineering playbook covers that side.

Implementation checklist for 2 December 2027

1. Inventory every agent, model and workflow touching hiring, worker management, credit or insurance decisions about people in the EU.

1. Classify each against Annex III points 4 and 5 and Article 6(3). Treat anything that profiles people as high-risk.

1. Assign roles in contracts: provider, deployer, model and tool suppliers, and who handles a change of purpose under Article 25.

1. Stand up the QMS, using EN 18286:2026 for the presumption of conformity on Article 17.

1. Run risk management with tests tied to every model, prompt and tool change.

1. Document data governance for fine-tuning and evaluation data, with bias examination under Article 10 and Article 4a safeguards.

1. Instrument run-level logging that links each decision to inputs, steps, model version and reviewer action.

1. Build oversight into the product: approval gates before adverse actions, override, an evidence view and a stop control.

1. Test security against injected instructions in uploaded documents and poisoned data.

1. Write instructions for use and an explanation template for Article 86 requests.

1. Complete the Annex VI assessment, declaration and CE marking; register before launch.

1. Define significant change in the QMS and route qualifying releases to re-assessment.

1. For deployers: train overseers, notify workers' representatives, inform applicants, keep logs for at least six months, and complete and notify the FRIA for credit.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our EU AI Act compliance engineering service builds the run-level logging, approval gates, stop controls and technical documentation that hiring and credit agents need before 2 December 2027, working alongside your counsel. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Regulation (EU) 2026/1744 (Digital Omnibus on AI), Official Journal L, 24 July 2026 — Publications Office of the European Union

1. AI Omnibus enters into force, 27 July 2026 — European Commission

1. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal L, 12 July 2024 — Publications Office of the European Union

1. Commission Implementing Decision (EU) 2026/2274 on the harmonised standards for high-risk AI systems, 12 October 2026 — Publications Office of the European Union

1. AI Act: regulatory framework for AI — European Commission

1. FAQ: Digital Omnibus — AI Act Service Desk

1. Article 111: AI systems already placed on the market or put into service — AI Act Service Desk

1. Timeline for the implementation of the EU AI Act — AI Act Service Desk

1. Annex III: High-risk AI systems referred to in Article 6(2) — AI Act Service Desk

1. Article 6: Classification rules for high-risk AI systems — AI Act Service Desk

1. Article 49: Registration — AI Act Service Desk

1. Consultation on the guidelines for the classification of high-risk AI systems, deadline extended to 23 July 2026 — European Commission

1. Employment: use cases and examples from the draft high-risk guidelines — AI Act Service Desk

1. Essential services: use cases and examples from the draft high-risk guidelines — AI Act Service Desk

1. First harmonised standard supporting the AI Act published in the Official Journal, 19 October 2026 — European Commission

1. Standardisation of the AI Act — European Commission

1. Article 26: Obligations of deployers of high-risk AI systems — AI Act Service Desk

1. Regulation (EU) 2016/679 (General Data Protection Regulation), Official Journal L 119, 4 May 2016 — Publications Office of the European Union

1. CCPA regulations on cybersecurity audits, risk assessments and automated decisionmaking technology, approved text — California Privacy Protection Agency