By Evaggelia Papadaki, Trust Services Compliance of ADACOM, Published in IT Security Pro no94
Understanding the Roles under the AI Act in the Context of a QTSP
A Qualified Trust Service Provider (QTSP), as defined under the eIDAS Regulation, may increasingly rely on artificial intelligence (AI) systems to support its trust services. These may include, for example, remote identity verification, fraud detection, ID document verification etc. The use of such systems introduces important considerations under Regulation (EU) 2024/1689 (the “AI Act”), particularly regarding the classification of roles under Article 3. In practice, a QTSP may simultaneously qualify as both a deployer and a provider, depending on how the AI system is used and integrated.
A QTSP will qualify as a deployer within the meaning of Article 3(4) of the AI Act where it uses an AI system developed by a third party in the course of providing its services. For example, where a QTSP relies on an external vendor to supply an AI-based identity verification solution which is capable of performing facial recognition, liveness detection, and document verification, the QTSP is using that system operationally. In this situation, the QTSP does not develop the AI system itself but applies it in a real-world context to verify user identities. As a deployer, the QTSP is required to use the AI system in accordance with the provider’s instructions, ensure appropriate human oversight and monitor the system’s performance and potential risks (Article 26 AI Act). Given that remote biometric identification systems are typically classified as high-risk AI, the QTSP may also be required to carry out a Fundamental Rights Impact Assessment under Article 27. However, it is worth noting that for a QTSP identity verification is legally significant as it enables the issuance of qualified certificates. When a QTSP acting as a deployer uses an AI system for onboarding (e.g. selfie + ID match) this is not a remote biometric identification from a wider pool (“Who is this person?”), but it is biometric verification used to confirm a specific claimed identity (“Are you this person?”). It will very likely still be considered as high-risk due to its function and impact and the QTSP cannot rely on the exclusion of Annex III of the AI Act to avoid high-risk classification.
A QTSP may also qualify as a provider within the meaning of Article 3(3) where it places an AI system on the market or puts it into service under its own name or trademark. This situation arises, for instance, where the QTSP integrates a third-party AI system into its own platform and offers AI-based identity verification as part of its branded trust services. Even if the underlying technology originates from an external vendor, the QTSP may be considered a provider because it presents the AI-enabled functionality as part of its own service offering. In such circumstances, the QTSP assumes the obligations applicable to providers, including the establishment of a risk management system (Articles 8-9), the establishment of a quality management system (Article 17), documentation keeping (Article 18), the preparation of technical documentation (Article 11), and the implementation of transparency and human oversight measures (Articles 13 and 14).
Overlapping roles & implications
The distinction between deployer and provider is not static. A QTSP that initially acts as a deployer may become a provider where it exercises greater control over the AI system. This transition is likely to occur where the QTSP substantially modifies the system, for example by retraining or fine-tuning the model using its own data. It may also arise where the QTSP changes the intended purpose of the system or markets the AI functionality under its own name as a proprietary solution. In such cases, the QTSP is no longer merely using the AI system but is effectively determining its characteristics and performance. Under the AI Act, this level of control justifies the imposition of provider-level obligations.
A QTSP may initially use a third-party AI solution to onboard users remotely. At this stage, the vendor qualifies as the provider, while the QTSP acts as the deployer. Over time, the QTSP may customise the system by adjusting identity matching thresholds, integrating the tool deeply into its onboarding workflow, and presenting the solution as part of its own qualified trust service offering. As a result, the QTSP may simultaneously qualify as both a deployer and a provider.
This dual role has significant regulatory implications. QTSPs already operate within a strict compliance framework under the eIDAS Regulation, which imposes obligations relating to security, reliability, and legal validity of trust services. When AI systems are introduced, these obligations are complemented by those arising under the AI Act. In particular, where AI systems involve biometric identification or other high-risk use cases, they are likely to trigger extensive compliance requirements. Accordingly, QTSPs must carefully assess their role under the AI Act on a continuous basis, taking into account how their use of AI systems evolves over time.
Moreover, a QTSP can act as distributor when it makes an AI system available on the market without modifying it and without being the provider or importer (it can, however, be the deployer), e.g. a QTSP offers a third-party AI verification tool to its enterprise clients as a standalone solution, without rebranding or modifying it. In this case the original developer is the developer for the purpose of the AI Act and the QTSP is the distributor. As a distributor, the QTSP must ensure the AI system is compliant, verify that documentation is available and refrain from distributing non-compliant systems.
In other cases, a QTSP may even be considered as an importer, when it brings an AI system from a non-EU provider into the EU market and makes it available for use in the EU. For example, a QTSP established in the EU procures a US-based AI identity verification solution and integrates it into its onboarding process. In this case the US company is the developer and the QTSP is the importer because it introduces the system into the EU market. As an importer, the QTSP must verify that the provider has complied with the AI Act, and that technical documentation and instructions are available. Even though the QTSP is not responsible for building the system, it acts as a gatekeeper into the EU market.
Each role carries different compliance obligations under the AI Act. Misclassifying roles, especially when these are overlapping, can lead to incomplete compliance, regulatory exposure and potential fines.
Disclaimer
This text is provided for general informational purposes only and does not constitute legal advice. A detailed legal assessment should be undertaken to determine the specific obligations applicable in each case.
Read also the full article in greek here: IT Security Pro – Issue 94.