L2-M2 / lesson 1 of 2
A consultancy builds one tool and buys another.
Start here / Watch the workplace case
2:39 · Narrated visual walkthrough · English captions and transcript
Watch for thisCompare the consultancy's purchased meeting assistant with the recruitment application it supplies under its own name.
Scene 1 of 6
An unchanged meeting assistant for internal work
A branded recruitment application supplied to clients
Map each system separately.
A consultancy buys a meeting assistant for its own staff and also builds a recruitment application for clients. Both products use AI, but the consultancy performs different activities around them. Do not assign one role to the company and apply it to everything. Start by drawing a separate system boundary for each use.
For the unchanged meeting assistant, the consultancy uses a supplied system under its authority in a professional context. That points to the deployer role for this activity. It still needs to check permitted data, configuration and local use. Buying from a supplier does not make the organisation's own operating decisions disappear.
The recruitment application is different. The consultancy develops a finished system on top of a model API and supplies that application under its own name. It needs to assess its role as provider of the system. It does not have to train the foundation model itself for system-provider responsibilities to become relevant.
The model and the recruitment application are related, but they are not the same thing. Upstream information can support integration, while the finished application's intended purpose determines its own assessment. A strong model benchmark does not establish that the recruitment workflow is fit for its use. Connect the evidence across layers without collapsing them.
Suppose the API contract calls the consultancy just a user and disclaims responsibility for hiring. That wording does not settle the consultancy's statutory role. Review the actual development, branding and supply arrangement. Contracts should support access to needed documentation, change information and cooperation. They cannot substitute for understanding which organisation performs each regulated activity.
The result should be a reviewable map, not a single badge. Record each organisation's activity, the system concerned, supporting evidence and unresolved questions. Keep the AI Act analysis separate from GDPR controller and processor roles. In the next activity, use what each organisation actually does to explain the responsibility that needs assessment.
After watching or reading / Think it through
Pause and form your answer, then compare the reasoning. This reflection is not scored.
No. Map the actual activity, development, branding and supply arrangement for each system. Using an unchanged tool and supplying a branded application require separate role assessments. Keep model and system layers, and data protection roles, distinct.
Use the role concepts below to explain the two activities. The written example returns to the same consultancy and its contract label.
Map each system and each organisation's activity.
One organisation can be provider and deployer in different contexts.
Draw a simple supplier, integrator, customer chain verbally. Keep the model and system layers separate.
Buying an API does not decide the role of the finished system.
A consultancy buys a language-model API and builds its own branded recruitment-screening application for clients. It also uses an unchanged third-party meeting assistant internally. The API supplier says it accepts no responsibility for the consultancy's hiring workflow.