When fine-tuning a large language model makes an insurer a provider under the EU AI Act

Two levels of role: the model and the system

The Act separates model-level roles from system-level roles. A provider of a general-purpose AI model is one party. A provider of an AI system is another. A downstream provider is a provider of an AI system, including a general-purpose AI system, that integrates an AI model. The model may be the provider's own or may come from another entity under a contract.

A fine-tuned LLM inside an insurer workflow can raise both questions at once. The insurer may be a deployer of the system, a downstream provider integrating a third-party model, and a possible downstream modifier of the model itself. The obligations differ at each level, so the classification record should address them separately for every use case.

The core definition is straightforward. A provider develops an AI system or GPAI model, or has one developed, and places it on the market or puts the AI system into service under its own name or trademark, for payment or free of charge. Commissioning a vendor to build the system does not move the provider role elsewhere if the insurer puts it into service under its own name.

The Act also provides that any distributor, importer, deployer or other third party is considered a provider of a high-risk AI system, and is subject to the provider obligations under Article 16, in the circumstances the provision lists. In practice, the questions to document are whether the insurer applies its own name or trademark, whether the change is a substantial modification, and whether the system's purpose has shifted from what the original provider intended. Separately, a high-risk system that has already had a conformity assessment needs a new one after a substantial modification, whether the system is further distributed or stays with its current deployer.

Fine-tuning techniques against the substantial-modification question

The Act does not map specific techniques to the substantial-modification test, and Commission guidance on GPAI modification distinguishes significant from minor changes without classifying methods in this way. The table below is interpretation, offered as a starting hypothesis to test and record, not a settled rule. In every row, the use case and the name under which the system is put into service still decide the outcome.

• Prompt engineering: Interpretation: usually closer to configuration than modification, because the model and its training are unchanged. The risk is a change of purpose, for example reusing a summarization prompt for risk scoring.
• Retrieval augmentation: Interpretation: the model is unchanged, but system behaviour depends on the retrieved content. Record the data sources and whether outputs now feed decisions about individuals.
• Parameter-efficient fine-tuning: Interpretation: the model weights are altered with new training data, so a modification record is needed. Whether it is substantial or significant turns on how far behaviour and performance change.
• Full fine-tuning: Interpretation: the strongest candidate for a substantial or significant modification, and it adds to cumulative training compute. Assess the model-level question as well as the system-level one.

Downstream modifiers of general-purpose AI models

A general-purpose AI model displays significant generality, can competently perform a wide range of distinct tasks, and can be integrated into a variety of downstream systems or applications. Models used only for research, development or prototyping before being placed on the market are excluded from the definition, which matters for pilots that never reach production.

A recital states that, for a modification or fine-tuning of a model, GPAI provider obligations should be limited to that modification or fine-tuning. One example given is adding information on the modifications, including new training data sources, to the existing technical documentation. The Commission's GPAI guidelines add that only those making significant modifications need to comply with GPAI provider obligations, not those making minor changes.

Compute is a further consideration. A recital states that cumulative computation used for training includes pre-training, synthetic data generation and fine-tuning, and that an initial floating-point-operations threshold leads to a presumption of systemic risk. An insurer's own fine-tuning counts toward that cumulative figure, so keep a record of the compute used for each adaptation. Two thresholds therefore run in parallel: substantial modification for high-risk systems, and significant modification for GPAI model obligations. A change can clear one and not the other.

High-risk classification and what a role change triggers

An Annex III AI system is always considered high-risk where it performs profiling of natural persons. For insurers, this is the practical screen. Underwriting support, risk assessment and pricing that evaluate individual applicants or policyholders are likely to involve profiling, and each should be checked against the Annex III entries. Customer communications drafting or document summarization that does not evaluate individuals sits in a different position, but the classification record should say why. If a lower-risk tool is later pointed at a decision about a person, the analysis must be repeated.

If the insurer is treated as the provider of a high-risk system, the provider obligations under Article 16 apply. These include a conformity assessment, a quality management system and technical documentation. Insurers have one relevant accommodation. For providers that are financial institutions subject to internal-governance requirements under Union financial services law, the quality management system obligation is deemed fulfilled by complying with those governance rules, except for paragraph 1, points (g), (h) and (i). A recital applies the same regime to insurance and reinsurance undertakings, holding companies and insurance intermediaries. Existing governance arrangements can therefore carry part of the load, but not all of it.

The operational point holds in either role. A deployer still needs to show what the system was permitted to do and what it did, so the evidence design should not wait for the role decision to be final.

Runtime enforcement and evidence in either role

Whether an insurer ends up as provider or deployer, it needs to show what its AI systems were allowed to do and what they did. Trussed enforces policy in the execution path: individual interactions and tool calls are allowed, redacted, blocked, or escalated for human approval, enforced at runtime, not reviewed after the fact. That enforcement produces continuous, audit-ready evidence mapped to the EU AI Act, and to NAIC, NYDFS, HIPAA and NIST for carriers operating across jurisdictions.

The scope is specific. Trussed does not perform fine-tuning, and it does not provide model lineage or dataset provenance. It does not make the provider-versus-deployer determination, which stays with the insurer's compliance function and the dated rationale described above. What it supplies is the runtime record of enforcement decisions, which supports the evidence an insurer would need to keep once the classification is settled.