Provider and deployer roles follow what each party does

Under the EU AI Act, a provider develops an AI system or has it developed and places it on the market or puts it into service under its name or trademark. A deployer uses an AI system under its authority, outside personal non-professional activity.

Those definitions sound tidy until a company commissions a custom system built with an external model, applies its own branding, changes the workflow, and operates it for employees. The role map then depends on facts, not the noun used in the contract.

This operating method determines the role from the exact arrangement and records the evidence supporting that decision.

A role belongs to one system

A company can deploy a purchased assistant, provide a custom application, and distribute another product at the same time. “We are an AI user” is therefore too broad for an inventory.

Record the exact system, intended purpose, version, market, name, and parties. Then assign provisional roles for that record. Keep the upstream general-purpose AI model separate because its provider duties concern the model, while downstream AI-system duties concern the application and use.

This separation matters in Skybridge. A Compsia production system may contain a model API, connector services, retrieval code, approval interfaces, and customer-owned source systems. Each party controls a different part of the path.

Five facts reveal the likely role

Use five questions to prepare the legal review:

The answer can be shared or contested. Record that uncertainty. A contract can allocate tasks, evidence, and cooperation, while statutory classification still follows the law.

Article 25 can change responsibility

Article 25 addresses responsibilities along the AI value chain for high-risk systems. A distributor, importer, deployer, or other third party can be treated as the provider when it places its name or trademark on a high-risk system, makes a substantial modification while it remains high-risk, or changes the intended purpose of another system so that it becomes high-risk.

Changing a color or prompt does not automatically settle the test. The material question concerns the system's compliance and intended purpose. Conversely, a seemingly small workflow change can matter when it moves an assistant into recruitment ranking or another Annex III use.

Record the baseline version, the change, its effect on performance and purpose, and the party authorizing release. Route potentially material changes to legal and technical review before production.

Map the model provider separately

Most enterprises will consume rather than develop a GPAI model. The upstream provider may supply documentation, acceptable-use terms, model information, and change notices. The downstream provider or deployer still owns the parts it controls.

Skybridge supports multiple model routes. That design makes a route register necessary. The system record should name the model used for the released task, because a list of every technically available model obscures the actual value chain.

The same applies to connectors. A gateway can hold the OAuth connection and execute a request. Compsia can define the permitted operation. The customer can determine whose records may be read. Responsibilities must follow those facts.

How the role question appears in Compsia delivery

Compsia sells a complete custom AI production system around a defined business result. Skybridge is the included environment for using and supervising supported capabilities. The AI Act role decision follows the exact development, branding, release, and operating arrangement.

The role may depend on who specifies the intended purpose, whether the system is offered under Compsia's name, how much the customer changes, and which party puts it into service. A customer using the system under its authority may be a deployer while Compsia may hold provider duties for the custom system. Another arrangement could produce a different map.

The release record therefore contains an approved role decision. It never turns “Skybridge uses third-party models” into “the model vendor owns every obligation.”

Put the role map into the contract and release record

Document:

• the parties and statutory roles assessed.
• the intended purpose and prohibited changes.
• required instructions and technical information.
• access to logs, incidents, and performance evidence.
• notice and approval for material changes.
• cooperation with authorities where required.
• exit, documentation return, and continuity responsibilities.

Review the map when branding, purpose, model, action authority, or operating control changes. The EU AI Act high-risk guide explains why intended-purpose changes can be decisive.

Run the role review as a short working session with the commercial owner, system architect, operating owner, and legal decision owner. Ask each person to draw who controls purpose, release, branding, and daily use before showing the contract labels. Differences between the drawings expose assumptions that need contractual or technical correction. Preserve the final map beside the system architecture so a future team can see why the role decision was made.

Provider and deployer questions

Is the software vendor always the provider?

The statutory definition depends on development, commissioning, branding, placing on the market, and putting into service. The software vendor may be a provider, but the contract label alone does not decide.

Can one organization be both provider and deployer?

Yes, depending on the system and activity. An organization can develop and put a system into service under its name, then use it under its authority.

Does using an external LLM make us only a deployer?

No automatic conclusion follows. The LLM provider can be the GPAI provider while your organization or supplier holds a separate role for the downstream AI system.