Trustworthy AI Framework: The BSI A5 Core Module in Practice

Executive Summary

• New EU requirements such as the AI Act and the Cyber Resilience Act are making the trustworthiness of AI systems a precondition that must be demonstrated. With the BSI A5 Core Module – the Horizontal Trustworthiness Core Module of the “AI Audit and Assurance Assessment Architecture” (A5) – a cross-technology, cross-sector and practicable trustworthy AI framework is available for the first time.
• Organizations in every sector need risk-based, systematic AI governance across the entire AI lifecycle. Isolated measures are no longer enough.
• For anyone responsible for the use of AI as a provider or as a deployer within an organization, fields of action arise in the areas of transparency, robustness, governance and fairness.
• Critical risks such as data poisoning, model manipulation, vulnerabilities in the AI supply chain and fairness bias are to be identified and reduced structurally through AI bias mitigation and AI-specific security testing.
• With the A5 Core Module, the German Federal Office for Information Security (BSI) provides the horizontal foundation, which can be supplemented by vertical, application-specific modules – so far by the Cloud Infrastructure module with a cross-reference to the C5 catalogue.

Why Trustworthy AI Now Needs a Framework

AI is attractive to almost every sector and business function as a way of increasing efficiency – from customer service and production through to the back office. Yet uncertainty about AI model risks repeatedly holds development back. And indeed, uncontrolled use of AI carries considerable reputational, legal and operational risks. Meanwhile, the regulatory grey area for AI applications is narrowing in the European Union.

With the EU AI Act and the Cyber Resilience Act, the demands placed on audit processes, traceability and AI risk management are rising sharply. The BSI A5 Core Module now provides a trustworthy AI framework that can help organizations along the entire AI value chain to work towards EU AI Act compliance and robust operations at the same time. One distinctive feature: the implementation guidance is consistently differentiated by provider and deployer role. Those who merely use AI systems will find just as much concrete orientation as those who develop them.

The BSI published A5 on 6 July 2026 as a community draft (version 0.9 of 30 June 2026). Comments could be submitted until 31 August 2026. A5 is therefore neither a law nor a standard, but it does address the evidence requirements arising from the EU AI Act and the Cyber Resilience Act, as well as future minimum standards for public administration.

For the financial sector, this is not the BSI’s first relevant publication: the Test Criteria Catalogue for AI Systems in Finance has been available since 2025.

How the BSI A5 Horizontal Trustworthiness Core Module Is Structured

Each criterion in the Core Module carries an identifier made up of a prefix and a number, for example GCS.3.1. The prefix assigns the criterion to a phase of the AI lifecycle, from overarching governance through data and development to validation and operation.

The abbreviations at a glance

• GCS: Governance, Compliance and Scope (overarching governance and risk processes)
• DEI: Design, Engineering and Integration (data and model development phase)
• VAV: Verification and Validation (security and robustness testing)
• DEP: Deployment (release and commissioning)
• OPS: Operations, Performance and Supervision (monitoring and incident management)
• RET: Retirement (orderly decommissioning)

Note: The following sections of this article group the criteria by topic rather than strictly following this order.

Characteristic of the module is the logic of parent processes: a process is defined once at an overarching level and is then made concrete for individual quality dimensions in the downstream areas. The quality management process from GCS.3.1, for example, feeds into transparency, robustness, performance, bias and explainability without the procedural logic having to be reinvented each time.

1. AI Governance Framework: Accountability Across the AI Lifecycle

Accountability must be clearly regulated across the lifecycle of AI systems.

The A5 Core Module sets out that:

• Every organization should embed an overarching quality management process for AI systems (GCS.3.1).
• A documented AI policy covering strategy, a structural and procedural organization as well as a roles and permissions concept should be established; risk management guidelines including risk ownership should be documented (GCS.2.3, GCS.2.1).
• Human oversight should be embedded structurally: from mechanisms for challenging and correcting decisions, through the avoidance of user manipulation, to competence-building and training processes (GCS.6). The risks of restricted human agency should be assessed, above all automation bias and excessive reliance on the system (GCS.1.4).

This does not apply solely to in-house developments. The use of pre-trained models and purchased AI products should likewise be documented and placed under AI governance (DEI.5.2, DEI.5.3).

Strategic benefit: Organizations protect themselves in regulatory terms and preserve their good reputation when AI is considered not only at a technical level but also with a view to its effects within the organization.

2. Data Quality & Data Management: The Foundation of Fairness

An AI strategy needs a data strategy.

• Data requirements and the separation of training, validation and test data should be defined, and data provision, preparation and storage should be documented across the entire data lifecycle (DEI.1.1, DEI.3.1).
• The rights of data subjects and users (e.g. access, rectification, erasure) should be implemented technically and organizationally (GCS.4.1).
• Operating and input data are also subject to their own data management and monitoring process (OPS.1.1, OPS.1.4).

Data quality is not “merely” a technical prerequisite for regulatory-compliant AI governance. The aim is to ensure that the basis for decisions is correct, fair and verifiable.

3. Transparency and Explainability: Prerequisites for Trustworthy AI

Transparency is a touchstone of strategic controllability.

It is often said that many AI systems operate as “black boxes” – not entirely without justification. In regulated and safety-critical environments, however, that is only acceptable to a limited degree. Accordingly, the BSI embeds the following in the A5 Core Module, among other things:

• a risk management process for explainability risks as well as a quality management process for explainability, particularly for decision-relevant models (GCS.1.3, GCS.3.6)
• transparency and user protection processes, including the labeling of AI interactions for users (GCS.3.2, GCS.6.5)
• the traceability of methods and decisions from design through to operation, including data provenance and logging (GCS.1.2, DEI.3.1, OPS.1.8)

Strategic benefit: Only transparency will make it possible to use AI systems in critical fields of application in a way that stakeholders will accept.

4. AI Bias Mitigation: How to Avoid Bias in AI Systems

Fairness is not an ethical add-on but a regulatory must.

The Core Module requires organizations to systematically:

• identify bias risks in the context of the intended purpose – from historical bias through sampling and model bias to implicit bias (GCS.1.7)
• define risk-based bias metrics with justified tolerance ranges and measure bias in the output (GCS.3.5)
• implement bias-mitigating measures and review their effectiveness (GCS.1.1)

Anyone who fails to manage and evidence fairness systematically risks regulatory sanctions. Deployers must additionally identify protected groups specific to their deployment and – where applicable – keep results available as part of a fundamental rights impact assessment (FRIA).

5. Security & Robustness: AI Red Teaming Against AI-Specific Attack Vectors

The technical security of AI applications is not just an IT topic but also a governance topic. Many organizations underestimate AI-specific attacks and rely on generic IT security.

The A5 Core Module systematizes the field according to concrete attack scenarios such as model evasion (circumventing detection through deliberately manipulated inputs), data poisoning (targeted contamination of the training data), model extraction (recreating the model through systematic queries), model stealing (theft of model knowledge by the same route), membership inference (inferring whether particular data were contained in the training set) and prompt injection (manipulation through prepared input text).

Measures addressed by the A5 Core Module include:

• simulated attacks against the assessed attack surface, e.g. adversarial testing and AI red teaming, to verify the effectiveness of countermeasures (VAV.1.1)
• input validation as well as checks for faulty, harmful or biased input data (GCS.5.3, GCS.3.3, OPS.1.4)

Also worth highlighting in the Core Module are:

• a quality management process for AI-specific cybersecurity (VAV.1.1)
• AI-specific vulnerability management spanning models, data, pipelines and interfaces (GCS.5.4)
• monitoring and incident management processes for security-relevant events in the AI supply chain (OPS.1.7, OPS.2.4)
• residual risks should be managed, documented and disclosed to relevant stakeholders in a manner appropriate to the audience (GCS.1.1)

In addition, a risk management process for robustness is required, covering criticality, partial failures and use for unintended purposes (GCS.1.6), along with a quality management process featuring edge-case analysis, testing under extreme conditions and procedures for determining uncertainty (GCS.3.3), as well as continuous monitoring for noisy, incomplete or atypical inputs with a fallback option and model downgrading (OPS.1.3). For deployers, the edge case in day-to-day operations is usually a more likely source of damage than a targeted attack.

For governance, this means that security testing should be extended in an AI-specific way – following security by design and with tiered security controls based on the risk, sensitivity and criticality of the system and data (GCS.5.2, GCS.5.3).

6. How to Establish AI Governance in Your Organization: Best Practices in Five Phases

The A5 criteria themselves are structured not by these topics but by the phases of the AI lifecycle. In this section we show how the two perspectives can be combined into AI governance best practices that work in day-to-day operations.

An seamless path from a low-threshold start to ongoing operation:

Phase 1 — Orientation & AI Inventory (Getting Started)

• Objective: Create an overview, capture risk, make the need for action visible.
• Core activities: Recording all existing and planned AI use cases (including “shadow AI”, purchased tools and generic assistants – cf. DEI.5.3); initial classification according to the EU AI Act risk logic; a rough assessment of regulatory exposure.
• Outcome: AI use case register and risk heat map.

Phase 2 — Readiness & Gap Assessment

• Objective: Determine what is missing for a responsible start.
• Core activities: (a) the data basis (suitability and quality criteria per use case, cf. DEI.2.1), (b) regulatory gaps (EU AI Act, GDPR, sector-specific requirements), (c) organizational maturity (roles, competencies, processes – cf. GCS.2, DEP.1.1, GCS.6.4).
• Outcome: Gap report with prioritized measures.

Phase 3 — Governance Design (Target Model)

• Objective: Set up a lean, binding steering framework.
• Core activities: AI governance guideline or policy (purpose, scope, roles, controls, release process – GCS.2.3, GCS.2.1, DEP.1.1); definition of responsibilities (e.g. AI officer, release board); definition of a minimal, risk-based control set; a three lines structure only where proportionate.
• Outcome: An adopted AI governance policy and a roles and accountability model.

Phase 4 — Implementation Support for the First Use Case

• Objective: Test governance on a concrete project.
• Core activities: Guiding the first (or pilot) use case through the release process; designing human oversight (GCS.6.3), transparency and labeling obligations (GCS.6.5), technical documentation (DEI.5.1) and the monitoring concept (OPS.1.2); where applicable, bias, fairness and robustness testing (GCS.3.5, GCS.3.3).
• Outcome: A documented, “governance-compliant” reference use case as a blueprint.

Phase 5 — Operation, Review & Scaling

• Objective: Make governance permanent and let it grow with adoption.
• Core activities: Ongoing monitoring (output quality and, where relevant, model drift, cf. OPS.1.5), review cycles, building AI competence and training the workforce (GCS.6.4), rollout to further use cases.
• Outcome: An established rhythm of operation and review.

Strategic Takeaways

• Executives do not have to develop AI themselves – but they are accountable for all of it. The A5 Core Module differentiates between the provider and deployer obligations set out in the AI Act.
• Transparency, fairness and security are not add-ons but mandatory components of EU AI Act compliance across the entire lifecycle, from governance through to retirement.
• The BSI criteria represent a concrete set of test criteria for AI systems that can be operationalised and deepened through modules for individual fields of application.
• Anyone setting up AI governance today is investing both in AI compliance and in future viability.

Conclusion: Choosing a Trustworthy AI Framework

The discussion around AI needs to move on from the technical playground – and not only in regulated sectors. With the A5 Horizontal Trustworthiness Core Module, the BSI provides a trustworthy AI framework that organizations in every sector can draw on to establish resilient AI governance and evidence EU AI Act compliance.

“It is not the use of AI that carries risk, but its ungoverned use.”

Consider the following:

• Where do AI systems exist, directly or indirectly, within my area of responsibility? Am I a provider or a deployer?
• How demonstrable are fairness, transparency and security measures today?
• Do defined AI governance roles and processes also exist for pre-trained models and the AI supply chain?

FAQ: Trustworthy AI, BSI A5 and EU AI Act Compliance

What is BSI A5 and what does the Core Module cover?

A5 stands for “AI Audit and Assurance Assessment Architecture”, a modular assessment architecture from the BSI that makes it possible to evaluate the trustworthiness of AI systems systematically. The BSI A5 Horizontal Trustworthiness Core Module – to give it its full name – forms the technology- and application-independent foundation and brings together the fundamental organizational and technical measures for trustworthy AI. It is complemented by vertical modules, so far the Cloud Infrastructure module. The BSI published A5 on 6 July 2026 as a community draft in version 0.9; the consultation period ran until 31 August 2026. A5 is therefore neither a law nor a standard.

What are the BSI A5 test criteria for AI systems?

The A5 Core Module brings together 55 individual criteria, each stating a requirement, the responsible party and any dependencies on other criteria, plus guidance differentiated by provider and deployer role. That guidance describes possible measures rather than prescribing them. As test criteria for AI systems they operate on two levels: organizationally, through processes that must be evidenced such as quality, risk and incident management; and technically, through measurable variables such as data quality thresholds, bias tolerance ranges, performance metrics and simulated attacks in the context of adversarial testing and AI red teaming (VAV.1.1). For the assessment methodology, the BSI initially follows the model of the C5 catalogue.

How does the BSI make the A5 Core Module available?

The A5 criteria are published as a PDF document and in machine-readable form in OSCAL format. This allows stakeholders to integrate the criteria into existing OSCAL-based tool chains for compliance work and audit support.

What do the A5 criteria abbreviations such as GCS, DEI or OPS mean?

Each criterion carries an identifier made up of a prefix and a number, for example GCS.3.1. The prefix assigns the criterion to a phase of the AI lifecycle: GCS (Governance, Compliance and Scope) covers the overarching governance, risk and quality management processes; DEI (Design, Engineering and Integration) the data and development phase from data planning to model architecture; VAV (Verification and Validation) validation and verification including attack simulation; DEP (Deployment) release and commissioning; OPS (Operations, Performance and Supervision) ongoing operation with monitoring and incident management; and RET (Retirement) orderly decommissioning. A process is frequently defined at an overarching level and then made concrete in the downstream areas. The quality management process from GCS.3.1, for example, feeds into other areas.

Were there BSI audit catalogues for AI before A5?

Yes. The AI Cloud Service Compliance Criteria Catalogue (AIC4) has provided a catalogue for AI services from the cloud since 2021. In 2025 it was followed by the Test Criteria Catalogue for AI Systems in Finance (preliminary version on 27 May 2025, final version on 30 July 2026) from the BSI’s AICRIV project. A5, which comes out of the AICRID project, generalises this approach: horizontal rather than sector-specific, and extendable in a modular way.

What are the provider and deployer obligations under the EU AI Act?

The EU AI Act assigns different duties to providers and deployers, and the A5 Core Module mirrors that split. Providers develop and supply AI systems; deployers use them in their own context, and the Core Module addresses all actors along the AI value chain. For most criteria, the BSI provides implementation guidance differentiated by these roles. Deployers therefore cannot rely on the provider documentation alone, but should review and supplement it for their own deployment context.

What are the high-risk AI system requirements?

The AI Act classifies AI systems according to their risk; high-risk AI systems are subject to the strictest requirements, including on risk management, data governance, technical documentation, record-keeping, human oversight as well as accuracy, robustness and cybersecurity. The A5 Core Module is not identical to the AI Act, but it covers precisely these fields with auditable criteria. Anyone who has to implement EU AI Act requirements can therefore use the Core Module as an evidence grid: it translates abstract legal obligations into operationalizable controls for trustworthy AI. Whether a system counts as a high-risk AI system must be determined in advance as part of the risk classification.

How do I implement human oversight in AI?

Human oversight in AI only becomes effective when it is tied to concrete control points. The Core Module requires an appropriate level of human agency and oversight with defined control points and escalation procedures (GCS.6.3), mechanisms for rejecting, challenging, correcting or suspending AI decisions (GCS.6.2), and a competence-building and training process for everyone involved along the AI supply chain (GCS.6.4). Implementing human oversight of AI therefore means: specified roles, documented rights of intervention and logging of interventions (OPS.1.8).

What distinguishes AI-specific risks from classic IT risks?

AI risks often arise from the learning behavior of the AI system, bias in the training data, insufficient explainability of the AI model or adversarial attacks. Unlike classic IT risks, they are dynamic rather than static: they change with the data, the model behavior and the deployment context. Effective AI risk management is therefore continuous rather than one-off and covers the entire lifecycle.

How are BSI A5 and the C5 catalogue connected?

For cloud-based AI systems, the Cloud Infrastructure module supplements the horizontal Core Module and creates the cross-reference to the established C5 catalogue for cloud services. For the assessment methodology too, the BSI initially follows the C5 model.

ISO 42001 vs BSI A5: which do I need?

ISO 42001 and BSI A5 are not mutually exclusive; they address different levels. ISO/IEC 42001 describes a certifiable management system for artificial intelligence and therefore covers organizational steering above all. A5 is a catalogue of audit criteria intended to make the technical and organizational trustworthiness of specific AI systems demonstrable. In practice, an existing AI management system can be used as a basis and supplemented with the A5-specific evidence.

How do I avoid bias in AI systems and evidence fairness?

Through bias measurement procedures, defined tolerance ranges and documented mitigation strategies, as required by the BSI in GCS.1.7 and GCS.3.5. The BSI explored this in more depth in its publication “Bias in Artificial Intelligence”.

What role does transparency play in regulatory requirements?

Transparency is a basic prerequisite for audits, user acceptance and system-side traceability. The Core Module embeds it horizontally, from the labeling of AI interactions through to data provenance.

Are bought-in AI models also affected by regulation?

Yes. The use of pre-trained models should be justified and documented, including a phase-out and continuity strategy with fallback options and migration paths (DEI.5.2); upstream AI products and their data flows should be documented (DEI.5.3), and the AI supply chain should be included in monitoring and incident management (OPS.1.7, OPS.2.4).

How do I build an AI quality management system?

Building an AI quality management system starts with the Core Module’s overarching parent processes: the quality management process (GCS.3.1) defines need, requirements, metrics, thresholds and test plans, and is then made concrete for individual dimensions such as transparency, robustness, performance, bias and explainability.