C5 attestation for AI SaaS: making models, training and inference audit-ready

This page is for providers of AI software as a service who are planning a C5 attestation, whatever their industry. AI software in healthcare with patient data has its own page, AI in healthcare; what applies to every SaaS provider, such as scope and evidence with a small team, is on the C5 for SaaS providers page. Whether a model provider is a subservice organisation is decided by two characteristics under section 3.4.6; the review per service organisation is shown on the subservice inventory page. What AIC4 covers and where it stops is explained on the AIC4 page.

What C5 says about AI and what it does not

The C5:2026 catalogue has no criteria for models, training data or model quality. In the German version, according to our full-text search, AI appears only once: OPS-18.01B requires the use of AI-based tools in vulnerability scans and penetration tests to be documented in a traceable way. That does not mean AI plays no part in the audit. An AI service is a cloud service, and all basic criteria apply to it; the models only change where and how they take effect.

The example: a customer service assistant

Fictitious example, not a customer. A provider operates an assistant for the customer service teams of energy suppliers and insurers. It suggests replies to emails and chat messages; the customers’ staff review and send them. The architecture:

• Application with web interface and interface to the customer’s ticketing system, operated on a public cloud platform in a region in Germany.
• Knowledge search per customer across product documents and tariff terms that the customer uploads.
• Own classification model that recognises and routes requests, fine-tuned by the provider and run on rented GPU instances.
• Language model from a model provider via API for the draft replies; if it fails, a fallback model from a second provider.
• Model registry with versions, training datasets and test results; a training environment in a separate account.
• Logs of all model calls with input, output, model version and response time.

Model dependencies: what can change and where it sits in C5

An AI service depends on components that change without any code change of your own. The following mapping is ours; the criteria are the points at which the auditor will ask for evidence.

OPS-01.03B requires the provider to continue meeting the requirements agreed with customers even in the event of capacity restrictions. For an AI service this means, in our assessment: the response time you commit to needs a plan for when GPU quotas run short.

Inference: two scope decisions before the audit

First: the fallback model. If you switch automatically to a second model when the model provider fails, you have a second service organisation that receives customer data. In our assessment it has to be treated like the first: in the directory of service organisations, with its method (carve-out or inclusive) in the system description and with the same region. PSS-12.01B requires customer data to be processed only in the agreed region; a fallback model in another region would break that commitment exactly when it matters. Either the fallback model is in scope with its region, or there is none and an outage is handled as an availability issue.

Second: what a model call logs. The catalogue distinguishes cloud service customer data, which the customer inputs or which results from its use, from cloud service derived data, such as records of who used the service, at what times and with which functions (section 1.2.1). In our assessment, the inputs and outputs of a model call are cloud service customer data, and metadata such as time, model version and response time are cloud service derived data. Different rules apply to each, so they belong in separate stores with their own retention periods.

Training and fine-tuning as an operational process

For the auditor, training is a process like any other: it needs policies, owners and evidence. Two criteria determine the scope here.

• DEV-12.01B: cloud service customer data from production is not used in test or development environments unless the customers have explicitly approved it. In our assessment, a training environment is not a production environment. If you fine-tune with real customer tickets, you need the explicit approval of every customer concerned and must be able to prove it. DEV-11.01B belongs with this: development and test environments undergo a risk assessment and get appropriate security measures, including backup where necessary.
• OPS-11.01B and OPS-11.02B: cloud service derived data may only be collected and used to administer and operate the service, with no commercial use beyond that purpose, and all purposes other than those inherent to the general operation of all cloud services are specified in the contract. If you want to use usage metadata to improve your model for all customers, check whether that is still operation of the service, and record the purpose in the contract in any case.

In the example, this solution is the easiest to audit: the classification model is fine-tuned only with data from customers who have agreed to it in writing, in a separate training environment, and every new model version goes through the same approval as a software change. Whether a model change in the period covered by the type 2 report belongs in the system description as a significant change is covered on the significant changes and events page; an example for AI services is on the AI in healthcare page.

AI-specific attacks without C5 criteria of their own

C5 does not mention prompt injection, extraction of training data or manipulated inputs. They still belong in the audit, via general criteria: in the risk assessment under OIS-07 and OIS-08, in the scope of penetration tests under OPS-22 and in the guidelines for customers under PSS-01, for example on the duty to review draft replies before sending them. AIC4 addresses such attacks explicitly in its Security & Robustness area.

Planning C5 and AIC4 together

Whether an AIC4 report makes sense depends on whether your customers need information on training, testing and monitoring of the models for their risk analysis; the catalogue does not create an obligation. In the example this applies to the own classification model, less so to the purchased language model. If you are planning AIC4, three points follow from criterion PC-01 as we read it (paraphrased; the wording of the AIC4 catalogue is authoritative):

• The C5 report has to cover the AI service itself and the AIC4 period.
• It needs at least the same report type and an unqualified opinion.
• It has to be available before the AIC4 report.

In practice this means the same periods, the same scope, and an audit team in which, as AIC4 recommends, at least one person with experience in data science or ML development tests the AI service. More on the areas and limits of AIC4 on the AIC4 page.

Neither a C5 nor an AIC4 report covers obligations under the EU AI Act; whether any apply to your service, and which, needs a separate legal assessment.

Evidence an AI SaaS provider should prepare

Possible gaps at AI SaaS providers

• Fallback model without contract and region. Cause: the switchover was built as a technical reserve, not as a service organisation relationship. Effect: in an outage, customer data leaves the agreed region, and the service organisation is missing from the system description. Remedy: add it to the directory, fix the region in the contract, or switch off the switchover.
• Fine-tuning with production data without approval. Cause: training runs in the data team, outside the change and approval process. Effect: DEV-12.01B is not met for the period; in our assessment a retrospective approval does not change that. Remedy: obtain approvals or restrict training data to customers who have agreed and to synthetic data.
• Model versions outside the change process. Cause: weights are loaded directly into inference. Effect: no tests and approvals as evidence for DEV-07 and DEV-10. Remedy: model registry as a mandatory step before every deployment.