Post-Market Monitoring Plan for Credit Scoring AI Under the EU AI Act

What Article 72 requires, and what it leaves to you

The AI Act classifies AI systems used to evaluate the credit score or creditworthiness of natural persons as high-risk, because they determine access to financial resources and essential services such as housing, electricity and telecommunication services. Providers of these systems must have a post-market monitoring system. Article 72(1) requires them to establish and document it in a manner proportionate to the nature of the AI technologies and the risks of the system.

The Regulation defines post-market monitoring as all activities carried out by providers to collect and review experience gained from the use of their systems, in order to identify any need to immediately apply necessary corrective or preventive action. That definition is outcome-oriented. A plan that describes data collection but has no defined path from detection to action does not meet its purpose.

Proportionality has a practical consequence. The data sources, metrics and cadences in the plan should be justified against the specific credit scoring system, not copied from a generic template. Record the rationale for each scoping decision so a supervisor can see why it fits the system's risks. Check each section of the finished plan against the Commission's template for post-market monitoring plans.

The components of a working plan

Treat the plan as an operational artifact with inputs, thresholds, owners and evidence outputs. Six components cover the ground a compliance team needs to define.

• 1. System scope and roles: Identify the credit scoring system, its intended purpose, and for each deployment who is the provider and who is the deployer.
• 2. Data sources: List what is collected, from where, how often, and under what arrangement with deployers. Define only the operational data the provider actually needs, and record the basis for it.
• 3. Indicators and thresholds: Specify the measures for performance, robustness, bias and drift that suit this system, with a threshold for each.
• 4. Triggers and corrective action: State what moves a finding into corrective or preventive action, who decides, and what the possible actions are.
• 5. Interaction and change analysis: List the other AI systems, devices and software the system interacts with, or record that none are relevant. State whether the system learns or is updated in operation and how that change is monitored.
• 6. Outputs and links: Name where each finding is recorded: risk management, the quality management system, technical documentation, logs and incident handling.

Choosing metrics and triggers

The Act does not prescribe a list of accuracy, robustness, bias or drift indicators for creditworthiness models, so the choice is yours and must be defensible. Common candidates include predictive performance against observed outcomes, stability of input and score distributions over time, behaviour under unusual or degraded inputs, differences in outcomes across relevant groups of applicants, and the rate at which human reviewers override or escalate decisions. Complaints and appeals from applicants are also a useful signal of problems the numeric indicators miss.

For each indicator, document the data source, the calculation, the review frequency and the threshold. Then define what happens at the threshold. A tiered approach works well: a first level prompts investigation by the model owner, a second level requires a documented decision by a named risk or compliance owner, and a third level triggers corrective action such as restricting use, retraining or rollback. The tiers matter less than the fact that each one has an owner and a recorded outcome.

The Regulation also expects monitoring to look at interaction with other AI systems and software where relevant, and to address risks from systems that continue to learn after deployment. For credit scoring, that means upstream data or scoring components and downstream decision tools belong in the plan if they exist.

Assigning ownership and review cadences

The provider owns establishing and documenting the monitoring system. Deployers have a monitoring role in operation, including human oversight. Neither role works without the other, so the plan needs data-sharing arrangements: what the deployer sends to the provider, in what form, how quickly, and what the provider returns when a corrective action is decided. Put these in contracts or technical interfaces, not in informal practice.

Assign every plan element to a named role, not a team alias. Typical roles include a model owner for indicator calculation, a risk owner for threshold decisions, a compliance owner for the plan itself and its documentation, and an incident owner for escalation. Record the same assignments for both provider and deployer sides.

Set two kinds of cadence. Continuous or near-real-time checks cover the indicators that can be automated and that need prompt action. Periodic reviews, at intervals you justify, cover trend analysis, threshold calibration and plan updates. Auditors will want to see that monitoring happens in operation, so the periodic review should consume evidence from the continuous checks rather than replace them. Where a credit institution is the provider or deployer, check how the plan sits alongside existing financial-sector procedures so that you maintain one process, not two.

Linking monitoring to risk management, records and incidents

The Regulation ties data gathered from the Article 72 system to the evaluation of other risks in the risk management process. Design that route explicitly. Each data source in the plan should map to a risk it informs, and each threshold breach should create an input to the risk register or equivalent. Recital 81 groups post-market monitoring with the quality management system and technical documentation, so findings that change the system's behaviour or risk profile should also update the technical documentation, with a traceable reference to the finding that caused the update.

For records, specify which automatic logs and operational records are inputs to monitoring, how long they are kept, and who can retrieve them. This is the point where your Article 12 record-keeping design meets the monitoring plan: logs are only useful as monitoring evidence if the plan states what they contain and how they are analysed.

For incidents, define in the plan how a monitoring finding is assessed against your serious-incident criteria, who makes that call, and how fast. The plan should reference the organization's incident reporting procedure instead of restating it, and it should show how the assessment is recorded whether or not a report results.

Where runtime enforcement evidence fits

Some of what a plan needs is evidence of what the AI system did in operation. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit or escalate-for-approval decisions to individual interactions and tool calls. That enforcement generates audit-ready evidence of what the system was permitted to do and what it did, mapped to the EU AI Act among other frameworks. In a monitoring plan, this evidence can feed data collection and record-keeping, and it shows that controls operate continuously, not only at review points. Retention and data residency are configurable and deployment is self-managed in the customer cloud, which matters when the plan must state where records live.

The boundary is important. Trussed does not provide model monitoring, model lineage or dataset provenance, and enforcement evidence does not replace performance, bias or drift analysis of the credit scoring model itself. It does not satisfy the plan as a whole.

The following remain the organization's own responsibility: defining the plan and its scope, choosing indicators and thresholds, assigning owners and cadences, deciding corrective actions, connecting findings to risk management and technical documentation, and making incident determinations. Use enforcement evidence as one input among several, and say in the plan which inputs it supplies.