EU AI Act vs MAS FEAT: how each framework treats AI fairness and accountability, and what evidence banks must produce

Legal force and scope

Regulation (EU) 2024/1689 was adopted on 13 June 2024 and is binding. It takes a risk-based approach with four categories: unacceptable risk, high risk, transparency risk, and minimal or no risk. Its stated purpose is to promote human-centric, trustworthy AI while protecting health, safety and fundamental rights. Obligations attach to a system's category and to the bank's role, so a bank must first establish whether it is acting as a provider or a deployer of each system.

MAS FEAT works differently. It is a principles-based supervisory framework, and the Veritas methodology supports it. A principles-based framework does not prescribe a fixed checklist per system category. The institution is expected to show how it interpreted and applied each principle to its own use cases.

Timing on the EU side needs care. As of November 2026, the Commission's Digital Omnibus on AI, proposed on 19 November 2025, would apply the high-risk rules from 2 December 2027 for stand-alone systems and 2 August 2028 for systems embedded in products. These are proposed dates, so programme plans should treat them as a scenario and track the proposal before fixing milestones.

Side-by-side: what each framework asks of a bank

The table compares the two frameworks on the dimensions a risk team usually has to map. Statements about MAS FEAT are kept at the level of its published principles and its principles-based character.

• Legal status: EU AI Act: binding regulation. MAS FEAT: principles-based supervisory framework, supported by the Veritas methodology.
• Structure: EU AI Act: risk categories with article-level requirements for high-risk systems. MAS FEAT: four named principles that the institution applies to its own use cases.
• Fairness: EU AI Act: fairness and non-discrimination appear in the recitals as non-binding ethical principles; binding duties sit in the articles. MAS FEAT: fairness is a named principle.
• Accountability and governance: EU AI Act: a risk management system that is established, implemented, documented and maintained. MAS FEAT: accountability is a named principle the bank must be able to explain internally and to the supervisor.
• Human oversight: EU AI Act: high-risk systems are designed, including with human-machine interface tools, so people can effectively oversee them while in use. MAS FEAT: expressed through the accountability principle rather than a system-level design duty.
• Records and documentation: EU AI Act: documented risk management and role-dependent obligations. MAS FEAT: evidence that the principles were applied, in a form the bank chooses and can defend.

Fairness and accountability are defined differently

The EU recitals refer to seven AI HLEG principles, including human agency and oversight, non-discrimination and fairness, and accountability. The recitals describe these as non-binding ethical principles that apply without prejudice to the Regulation's legally binding requirements. A governance document should therefore not cite the recitals as the obligation. The enforceable requirements are in the articles, and a fairness position under the Act is built from those requirements, such as risk management and human oversight.

MAS FEAT names fairness and accountability directly as principles. The practical consequence is a difference in the question a supervisor asks. Under the EU statute, the question is which requirement applies and whether the bank can show it was met. Under a principles-based framework, the question is how the bank interpreted the principle for a given use case and what shows it holds in practice.

Both framings reward the same habit: tie every fairness or accountability claim to an artifact that a third party can inspect. A statement in a policy document is not evidence. A test report, an approval record or an enforcement decision is.

Which evidence comes from design time and which from runtime

Model design, bias testing and validation happen before and around deployment. They produce the evidence that a model was built on suitable data, tested for discriminatory outcomes and validated against its purpose. Runtime enforcement does not replace any of this, and a runtime control layer cannot establish that a credit model is fair. Teams that blur this boundary will overstate what their controls prove.

Runtime evidence answers a different question: what was the AI system permitted to do, and what did it do on this interaction or tool call. The Act's risk management system is described as one that is maintained, which implies a continuing process rather than a one-off artifact. Human oversight is framed around the period of use. Both point to evidence of operation: records of policy decisions, of content that was redacted or blocked, and of actions escalated to a named person for approval.

For bank use cases such as credit scoring, classify each system against the Act's high-risk category first, then assign each evidence item to one side. Where a bank uses third-party general-purpose models, keep the model provider's obligations separate from the bank's own obligations as operator of the system built on top. The evidence each party can produce differs.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. It can allow, redact, block or escalate an interaction for human approval, and it generates audit-ready evidence from that enforcement, mapped to the EU AI Act. Its scope is individual interactions and tool calls. It does not test models for bias, validate them or document their design, and it does not claim a MAS FEAT mapping.

The relevance for risk leaders is examiner scrutiny and model risk management: runtime evidence that complements, and does not substitute for, development and validation records. Insurance is the regulated financial sector where Trussed is deepest, with deployment as self-managed software in the customer cloud and configurable retention and data residency.