AI software for hospitals: planning a C5 attestation with model provider and inference

This page is for providers of AI software for hospitals and other healthcare organisations who are planning a C5 attestation. It covers the points that only arise with AI: model provider, inference, data flows and approval of model changes. Whether and how Section 393 SGB V (Book V of the German Social Code) applies, including the processing location and an establishment in Germany, is explained on the Section 393 SGB V page. How to define the subject matter in general is described on C5 scope. For auditing the AI system itself, beyond the infrastructure, the BSI is drafting a separate audit framework, A5. AI SaaS outside healthcare is covered on C5 for AI SaaS; for vendors of practice software without an AI focus, see C5 for practice software vendors.

The example: an AI documentation assistant for hospitals

Fictitious example. A provider develops software that creates draft physician letters from dictated notes and data from the hospital information system. Physicians review and correct every draft before it goes back into the hospital information system. The architecture:

• Application with web interface, interface to the hospital information system, pre-processing and prompt construction, operated by the provider on a hyperscaler platform in a region in Germany.
• Inference in two possible variants: (A) calls to the language model of an external model provider via an API, or (B) an open-weight model that the provider runs itself on rented GPU instances.
• Data storage for inputs, drafts, logs of model calls and a vector database with templates per hospital.
• Operations and support by the provider’s own team; monitoring via a third-party logging service.

The software can look the same in both variants. For the attestation they are two different subject matters.

Is the model provider a subservice organisation?

In variant A, as a rule, yes. The catalogue treats a service organisation as a subservice organisation for the purposes of the report if two characteristics apply in combination: its service is relevant to customers’ understanding, and controls that the provider expects at the service organisation (in the catalogue: complementary subservice organisation controls, CSOC) are required in combination with the provider’s own controls to meet the criteria. If the provider’s own monitoring controls already cover the service organisation’s controls sufficiently, it is not a subservice organisation in this sense. In our assessment, a language model that generates every draft physician letter and receives patient data in the process meets both characteristics.

The provider then chooses between two methods and states the choice in the system description:

Carve-out does not remove accountability: the catalogue states expressly that the provider remains accountable. For the model provider, the system description states the company name, the location of processing and storage (country level is sufficient), an assessment of complexity and dependency, and whether C5 reports are available.

In variant B the provider runs the model itself. Model operation, model updates and GPU configuration then belong in its own subject matter, and the GPU platform is the subservice organisation.

Scope decisions that only arise with AI

Four decisions should be settled before the audit, because they change the system description, the controls and the evidence:

1. External API or own model. Variant A shifts controls to the model provider and requires monitoring it, variant B brings them into your own scope. If you want to switch between the two, do so before a type 2 period starts.
2. Logs of model calls as customer data. Prompts and outputs contain patient data. In our assessment they belong in the subject matter, with retention period, region and access rights. PSS-12.01B requires customer data and backups to be processed and stored only in the agreed region; that then also applies to these logs and to the logging service.
3. Training and fine-tuning. If customer data flows into a model, you need a documented decision on whether this happens, on what legal basis and with what separation per customer. If you rule it out, you should be able to prove that contractually and technically, for example through the configuration at the model provider.
4. Separation per hospital. A shared vector database for several customers is a case for OPS-30 and OPS-31 (separation of datasets): separation along a documented layer model and a risk assessment that is reviewed at least annually.

Approval: treat model changes like software changes

A new model or a new model version changes the behaviour of the software, even if no code has changed. We recommend taking model changes through the same approval process as software changes, with a test against a fixed test set, approval by a named role and a record. Three criteria from C5:2026 help here:

• DEV-13 requires a maintained list of software components for every developed or integrated component; the catalogue names an SBOM as one way to meet it. In our assessment, a model with its version and origin belongs on this list.
• DEV-14 requires third-party software to be obtained only from trusted sources and its authenticity to be verified whenever possible. For model weights in variant B this means a defined source and a checksum or signature.
• SSO-07 requires transparency about service organisations: document data flows and inform customers which service organisations themselves use subcontractors. With model providers that use third-party data centres themselves, this quickly spans several tiers.

In a type 2 report, the system description has to disclose significant changes to the system of internal control during the audit period. Whether a model change is significant is for the provider and the auditor to judge. In our view, a change of model provider, that is, of a subservice organisation, should be treated as significant. So do not plan such changes to happen unnoticed in the middle of the period.

What the hospital has to contribute

Part of the security lies with the customer. The system description names the complementary customer controls (also called complementary user entity controls, CUEC) that the provider assumes when designing its controls (section 3.4.5.1 no. 7), and the auditor points out in the report that the criteria can only be met if the customer’s controls are effective. For AI software, typical candidates are:

• physicians review every draft before it is adopted into the hospital information system,
• the hospital manages user accounts and roles and revokes access when people leave,
• the hospital only transmits the data needed for the purpose.

Word these controls so that the hospital can implement them and provide evidence. For customers within the scope of Section 393 SGB V this is more than a formality: the law requires the complementary customer criteria contained in the audit report to be implemented. The catalogue lists such customer criteria for selected C5 criteria as an aid to identifying the CUEC; how the statutory term relates to the CUEC is discussed on the Section 393 SGB V page.

Evidence the auditor will want to see

What about AIC4?

AIC4 is a voluntary BSI criteria catalogue for AI cloud services, designed as an extension of C5 and with C5 as a prerequisite; it is available in English only and dates from 2021. Section 393 SGB V requires a C5 attestation for the basic criteria or evidence under the C5 Equivalence Ordinance (C5GleichwV), not an AIC4 report. The BSI’s draft for auditing AI systems is described on the BSI A5 page.

What needs to be clarified separately

A C5 attestation answers questions of information security. It does not answer whether the software is a medical device, whether it falls under the EU AI Act or which data protection requirements apply. The BSI itself does not describe C5 as a data protection standard. If an application is to be listed as a digital health application, the Technical Guideline TR-03161 also comes into play; see TR-03161 and C5. These questions need a separate legal assessment in each case.