The EU AI Act's obligations for high-risk systems — including the Annex III creditworthiness-assessment category — apply from August 2, 2026, and for deployers of consequential systems the statute's Article 27 adds a duty many institutions have only begun to price: a fundamental rights impact assessment (FRIA), required before first use of high-risk AI for credit scoring and life-insurance pricing by the entities the article names. Deployers' obligations under Article 26 — use per instructions, input-data governance, logging, human oversight — arrive the same day; the files are different, and both have deadlines.
3G Times publishes information, not legal advice. Classification, roles, and FRIA scoping under the AI Act belong with European counsel and, where applicable, the market-surveillance authority.
Who owes what on August 2?
The Act splits duties by role. Providers — developers of high-risk systems — carry the heaviest load: the Article 17 quality-management system, risk management across the lifecycle, data governance for training sets, technical documentation, automatic logging, post-market monitoring, and serious-incident reporting, backed by conformity assessment and CE marking. Deployers — the banks and fintechs putting scored applicants through the system — owe Article 26's operational duties: use the system per the provider's instructions; ensure input data is relevant and sufficiently representative for the intended purpose; keep the logs the system generates; assign competent human oversight per the provider's design; inform workers and, where the AI Act's transparency articles apply, the affected persons; and not subvert the oversight the provider built. A bank using a vendor model is a deployer; the same bank that materially retrains the model becomes a provider for those changes — the role boundary procurement must draw explicitly.
What is the FRIA and who must write one?
Article 27 addresses deployers that are public bodies, private entities providing public services, and deployers of the two Annex III categories the legislature singled out — creditworthiness evaluation and life-insurance and health-insurance pricing. The assessment's required content is enumerated: the deployer's processes and period of use; the categories of persons and groups likely to be affected; the specific risks of harm to those groups; the human-oversight measures; and the remediation steps if risks materialize. For a credit operation, that reads as a document the institution half-owns already — the fair-lending and model-governance file contains the population analysis, the monitoring design, and the escalation paths — restated in fundamental-rights vocabulary, with the gap analysis being the actual work: what the fair-lending file measures and what the FRIA must state rarely overlap perfectly, and the delta is the project.
| Obligation | Role | First line of evidence |
|---|---|---|
| Quality-management system (Art. 17) | Provider | QMS manual, procedures, audit trail |
| Post-market monitoring and incident reporting | Provider | Monitoring plan; serious-incident log |
| Instructions and input-data governance | Deployer | Procured instructions; data relevance review |
| Logging and human oversight | Deployer | Retained logs; oversight-role definitions |
| Fundamental rights impact assessment (Art. 27) | Named deployers, incl. credit scoring | The FRIA itself, before first use |
What does human oversight require in a credit shop?
The Act's oversight articles assume oversight can bite: the overseer must understand the system's capabilities and limitations, remain able to disregard or override output, and intervene or halt where risk concentrates. In underwriting practice, that means the reviewer with override authority is trained on the model's known failure modes, the override path is real (not a UI fiction the queue penalizes), and overrides are logged with reasons that monitoring reviews. The supervision questions write themselves: what share of automated decisions receive meaningful review, what the override rate is by segment, and what happened to the overrides against outcomes — the same questions fair-lending exams ask, which is the compliance opportunity: one oversight architecture, two regimes satisfied.
How should the pre-August program be sequenced?
Classification first: inventory every AI system touching Annex III use cases and name its role per system — provider, deployer, or both by modification. Then the two files: the deployer file (instructions procured, input-data relevance documented, logging verified, oversight roles staffed) and, for credit deployers, the FRIA built from the fair-lending and model-governance record with the rights-vocabulary delta closed. Vendor flow-downs run throughout: the provider's Article 17 conformity documentation, instructions, and incident-notification duties arrive through contracts, and the market's paper has been converging since the August 2025 general-purpose-model deadline taught everyone what transition-day shortages look like. Member-state market-surveillance authorities and the EU's AI Office publish the operative guidance; the program should track both, because the penultimate drafts of QMS expectations are already visible.
What does this mean in practice?
- Run the role-boundary analysis per system now. Deployer today, provider after a retrain — the boundary is a procurement clause and a change-management gate.
- Build the FRIA from the fair-lending file. The delta, not the document, is the work; start with the population and harm analysis that exists.
- Prove oversight with data. Override rates, review coverage, and override outcomes are the exam answer for both the AI Act and fair-lending.
- Calendar the incident-reporting interface. Serious-incident duties are the provider's, but deployers detect them first — the escalation path between the credit floor and the vendor is a contract clause.
August 2, 2026 is the Act's high-risk day, and credit scoring stands in the front row of Annex III. The institutions that read the FRIA as a re-statement exercise — rights vocabulary over an evidence base they already maintain — will meet the date with the file; the ones that read it as new philosophy will meet it with a consulting engagement and a deadline.
One calibration note for the FRIA's harm section: the Act's notion of harm to health, safety, and fundamental rights reads naturally against the nondiscrimination instruments — the Charter's Article 21 among them — so the populations analysis imports the protected-attribute lenses fair-lending already maintains on the US side. Multinational credit operations can therefore run one population-and-harm core per model and express it in the vocabulary each regime demands, which is how the August deadline becomes a documentation exercise rather than a philosophy seminar.
How does the AI Act interact with GDPR for credit models?
In layers, not in conflict: GDPR governs the personal data — lawful basis, Article 22's automated-decision constraints, transparency about logic; the AI Act governs the system — risk classification, oversight design, the FRIA. The practical program reads them as one file with two indices, because the populations, the harm analysis, and the human-review architecture are the same facts. Deployers that document once, file twice, avoid the divergence that examiners of either regime probe first.
Frequently asked questions
Does the AI Act apply to non-EU fintechs serving EU customers?
Where the system's output is used in the Union, providers outside the EU are within scope, and deployers inside carry the deployer duties regardless of where the model was built. The territorial analysis is fact-specific — placing-on-the-market concepts do the work — and belongs early in the classification memo.
Is a FRIA the same as the Colorado-style impact assessment?
They rhyme — populations, harms, oversight, remediation — but the regimes differ in trigger, addressee, and enforcement. Programs built on one common evidence core, filing twice in each regime's vocabulary, manage both without double work.
What happens on August 3 if a deployer has no FRIA?
The Act's enforcement is national: market-surveillance authorities can require compliance, restrict use, and levy administrative fines scaled to turnover. The sharper commercial risk for banks is counterparty: supervision expectations travel through prudential examiners who ask for the file without waiting for the AI Act specialist.
For more context, read Colorado AI Act After the Delay: What Deployers of Underwriting Models Must Build by June 30.
For more context, read utah ai policy act sb 149.
For more context, read dora ict third-party providers.