EU AI Act Applicability to US Credit Scoring Providers

Step 1: Establish territorial reach

The Regulation applies to providers that place AI systems on the market or put them into service in the Union, irrespective of whether they are established in the Union or in a third country. A US vendor that licenses a scoring model to an EU lender, or makes a hosted scoring service available to one, should test itself against this route first.

A second route exists independently. The Regulation also applies to providers and deployers established or located in a third country where the output produced by the AI system is used in the Union. A US fintech that runs the model entirely in the US and returns scores by API to an EU lender can therefore be in scope even if it argues it has placed nothing on the EU market. The stated rationale is to prevent circumvention and to protect natural persons located in the Union.

Two details deserve care. The recital describes output intended to be used in the Union, while the scope provision refers to output that is used in the Union. Document the analysis against both formulations. Authorised representatives of providers not established in the Union are also named among the persons within scope, so a US provider should expect that role to matter for its EU presence.

Practically, keep a record of which API endpoints, model versions and customer contracts serve EU lenders. That record is the factual basis for the territorial analysis and for any later question about where output was used.

Step 2: Classify the product

The recitals state that AI systems used to evaluate the credit score or creditworthiness of natural persons should be classified as high-risk, because they determine access to financial resources or essential services such as housing, electricity and telecommunication services. The Commission's guidance lists creditworthiness evaluation of natural persons among high-risk uses in access to essential private and public services.

Two carve-outs are stated. AI systems provided for by Union law for detecting fraud in the offering of financial services are not considered high-risk, and neither are systems used for prudential purposes to calculate the capital requirements of credit institutions and insurance undertakings. A score that serves both a credit decision and a fraud purpose needs a documented rationale for each use. Do not assume the carve-out covers the whole product because one function qualifies.

The high-risk language concerns natural persons. If part of your portfolio scores businesses, assess that product separately and record the reasoning rather than applying a blanket conclusion either way.

The Regulation is also stated to be complementary to existing Union law on data protection, consumer protection and fundamental rights. Rights and remedies under that law remain unaffected, so the AI Act analysis sits alongside, not in place of, those workstreams.

Step 3: Assign provider and deployer roles

The Commission describes obligations as split between providers and deployers. Its example is a developer of a screening tool as provider and a bank using that tool as deployer. In the usual arrangement, a US fintech that develops and sells the scoring model is the provider, and the EU lender that uses scores in credit decisions is the deployer. Roles follow the facts of each arrangement, so confirm them per contract rather than per company.

Provider-side duties attach to the system itself, and a third-country provider should plan for the authorised representative role noted above. Deployer-side duties attach to how the lender uses the system. The Commission states that operators providing high-risk systems that carry out creditworthiness assessments must assess the impact on fundamental rights and notify the national authority of the results. That makes the lender a consumer of your evidence: it will need material about how the system behaves to complete its own assessment.

A related recital addresses an EU operator that contracts an activity to a third-country operator where an AI system performing that activity would qualify as high-risk. The Regulation can reach those arrangements even when the system is not placed on the market, put into service or used in the Union in the ordinary sense.

Write the role allocation into the lender agreement, including who supplies which documentation and who owns reassessment when guidance changes.

What runtime enforcement can and cannot evidence

Some requirements are operational and can be evidenced from how the system runs. Others are development-time artefacts that no runtime control produces. Separating them early avoids overstating what a tooling investment delivers.

Conformity assessment, quality management, and dataset and model documentation sit outside runtime control. They come from the development and release process. Records of operation, enforcement of usage rules and human approval steps are where runtime evidence is relevant. This mirrors how examiners approach model risk management: they expect documentation of how a model was built, and also evidence of what it was allowed to do and what it did in production.

Trussed enforces policy in the execution path of models, agents and tool calls, applying allow, redact, block, rate limit or escalate for human approval at the level of individual interactions. That enforcement generates continuous audit-ready evidence mapped to the EU AI Act, among other frameworks. For a scoring provider, this can support operational evidence such as which interactions were permitted, which were blocked or redacted, and which were escalated for human approval. Deployment is self-managed in the customer cloud, with configurable retention and data residency, which bears on where EU-related evidence is held.

Trussed does not cover model or dataset provenance, and it is not a route to compliance on its own. It addresses one part of the evidence set, the part produced when the system runs.