Public Body Deployer (EU)
stable public-body-deployer-eu · v1.0The enterprise-ai-deployer library read from the public seat. Two seats the EU AI Act names overlap here and this profile is their union. Art.49(3) binds deployers that are public authorities, Union institutions, bodies, offices and agencies or persons acting on their behalf: before a high-risk Annex III system is put into service or used, the body registers itself, selects the system and registers its use in the EU database, with systems in the Annex III point 2 area carved out. Art.27 binds bodies governed by public law and private entities providing public services: before first use, an assessment of the impact on fundamental rights, notified to the market surveillance authority under Art.27(3) on the filled-out template referred to in Art.27(5), with Art.27(4) allowing the relevant sections of a data protection impact assessment to be cross-referenced rather than rewritten. The two lists do not coincide. A state school and a municipal housing agency sit in both, a private concessionaire running a public transport service sits in the second only and a Union agency sits in the first. Art.27 also reaches deployers of the creditworthiness and life and health insurance systems of Annex III points 5(b) and (c); that arm is a sector duty rather than a public seat and stays where it is, on the base profile's conditional AIG-046 row. Nothing here replaces the base. The overlay states only the rows the seat or the risk class changes or annotates and enterprise-ai-deployer supplies the rest, so the profile is reached by what an organisation is and what it deploys rather than chosen from a list. Each row's note names which of the two seats its clause binds. Where a clause binds every deployer of a high-risk system the note says both. Two clocks run. Under Art.113 as amended by Regulation (EU) 2026/1744, Chapter III Sections 1, 2 and 3 apply from 2 December 2027 to systems classified high-risk under Art.6(2) and Annex III (ADR-025), which is when the Art.26 and Art.27 duties annotated below become enforceable; Art.4 AI literacy is live already. Art.111(2) gives high-risk systems intended for use by public authorities and placed on the market before that date until 2 August 2030 to comply, so a public deployer's legacy estate has a longer runway than its next procurement and the inventory has to record which system sits on which clock.
- Roles
- Deployer
- Deployment models
- Cloud, multi-tenant SaaSCloud, single tenantOn premisesHybridEdgeOn deviceEmbeddedAir gapped
- Risk classes
- high-risk-annex-iii
- Jurisdictions
- EU
- Frameworks
- EU-AI-ActISO-42001NIST-AI-RMFNIST-AI-600-1OWASP-LLMOWASP-AGENTICGDPRSOC2ISO-27001NIST-800-53CSA-CCMCSA-AICM
GOV · Governance & Risk
IAM · Identity & Access Management
The deployer's own repositories and pipelines, including the prompt and configuration repositories for the AI systems it integrates.
Administrative access to the deployer's own production estate is its own duty, whoever built the AI system running on it. The administration of the provider's service reaches the deployer as a tenant administration console, which is a designated system like any other.
DAT · Data Protection
Art.26(9) binds both seats: the deployer uses the information the provider supplies under Art.13 to carry out the data protection impact assessment it owes under Art.35 of Regulation (EU) 2016/679 or Art.27 of Directive (EU) 2016/680. Art.27(4) then runs the other way for the Art.27 seat, letting the fundamental rights impact assessment cross-reference the relevant sections of this one. The two stay separate artefacts on separate legal bases and the cross-reference is what stops the overlap being written twice. At a public body the data protection assessment is frequently already on file from the underlying processing, so the order matters: read it first, then write only the fundamental rights elements it does not reach.
The deployer taking a decision on the system's output is the controller for Art.22.
APP · Application Security
Applies to the deployer's own development, including the integrations, prompts and agents it builds on procured models. The provider's lifecycle for the product is evidenced through AIG-032.
The deployer's own estate and integrations. The provider's test reports for the product are reviewed under VND-006.
The deployer's own builds. The product's bill of materials is the provider's, obtained under VND-002 where contracted.
The deployer's own pipeline. Integrity of the product's releases is the provider's.
The processing specification covers the input pipelines the deployer controls, which is where Art.26.3 input data relevance is tested.
Applies where the deployer executes model-generated or third-party code. Where the sandbox is a provider feature the deployer holds the provider's description of its limits.
INF · Infrastructure & Cloud Security
The deployer's own systems. For the hosted tier the provider's baseline is inherited and evidenced under VND-004.
The tenant separation clause is the provider's. Segmentation of the deployer's own estate is its own.
The deployer's own infrastructure. The provider's availability architecture is evidenced under VND-006 and BCM-010.
MON · Monitoring & Logging
Art.26(6) sets a floor rather than a period and binds both seats: at least six months for the automatically generated logs of a high-risk system under the deployer's control, longer where Union or national law requires it. At a public body the longer period is the usual case, because public record-keeping and archiving rules commonly reach the same records, so the retention schedule names the rule that sets the period for each system rather than defaulting to six months. The Art.12(3) fields a remote biometric identification log has to carry are stated on AIG-020.
VND · Vendor & Third-Party Risk
The deployer is the controller: it obtains the provider's sub-processor register and objection route under VND-002. Where the deployer is itself a processor for its own customers, the register is its own.
The control through which the deployer evidences every hosted-tier control inherited from a cloud provider.
INC · Incident Response
Includes informing the provider of a risk or incident found in use (Art.26.4).
The deployer is the customer notified. The provider's commitment is contracted under VND-002 and the deployer's own duties to data subjects and authorities run through INC-005. Where the deployer processes personal data for its own customers, the row is its own.
BCM · Business Continuity
The continuity control for every AI system the deployer does not host.
AIG · AI Governance
The inventory entry for a high-risk Annex III system carries two register references and this control holds both sides of the pair. Art.49(1) registration of the system is the provider's and is stated here; Art.49(3) registration of the deployment belongs to the Art.49(3) seat and sits on AIG-045, so the entry reads the provider's filing and the body's own filing together. The entry also records which clock the system sits on: Art.111(2) gives a high-risk system intended for use by a public authority and placed on the market before 2 December 2027 until 2 August 2030, while a system procured after that date complies from first use. The Art.6(2) and (3) classification record is unchanged from the base.
Two assessments, not one. The rows are kept apart so a reader does not merge them. AIG-006 is the impact assessment every deployer runs before use. Its anchor is ISO/IEC 42001 A.5 and it binds both seats. AIG-046 is the Art.27 fundamental rights impact assessment and binds only the Art.27 seat, bodies governed by public law and private entities providing public services, which is why Art.27 maps informatively onto this control and fully onto that one. Where the AIG-006 assessment already covers an Art.27 element the fundamental rights assessment cites the section rather than repeating it, the same reuse Art.27(4) allows against a data protection impact assessment.
Obtain the intended purpose, deployment context and design documentation from the provider (AIG-015 documentation, AIG-034 instructions for use). The deployer's own statement of purpose and context for each use is the AIG-039 use register.
Obtain the provider's verification and validation summary (AIG-034). The deployer's acceptance checks in its own context are the pre-deployment checks in AIG-009 and, where the system scores people, the in-production evaluation in AIG-025.
The deployment plan and the substantial-modification definition are the deployer's. The same definition is the Art.25 test: a substantial modification makes the deployer the provider.
Obtain the provider's training data summary (AIG-015, released under AIG-034). Where the deployer fine-tunes or evaluates a model on its own data, the practices apply to that data and the row is its own.
Obtain the provider's provenance statement for the training data (AIG-015). Provenance of data the deployer fine-tunes or evaluates on is its own.
Screening of the provider's training and evaluation sets is the provider's. Evaluation sets the deployer builds from its own data carry the DAT-024 screening result.
The documentation is the provider's. The deployer's evidence is the released version, held against the inventory entry and matching the deployed version.
Art.26(11) binds every deployer of a high-risk Annex III system, so both seats: a person subject to a decision the system makes or informs is told the system was used. Art.86(1) adds the right to obtain clear and meaningful explanations of the role the system played in the decision and the main elements of the decision taken, with the Annex III point 2 area excluded and with room for Union or national law to restrict it. The public body's own duty to give reasons for an administrative decision runs alongside and is not restated here: this row tests the notice and the explanation route, not the legality of the decision.
Carried from the base. The explainability documentation comes from the provider under AIG-015 and this profile uses it twice: it is what the Art.86(1) explanation is built from and it is the evidence behind the human oversight element the Art.27 seat has to describe at point (e) of its assessment. The first use binds both seats and the second only the Art.27 one.
Art.26(5) binds both seats. The deployer monitors operation against the instructions for use and informs the provider of the risks it identifies; where a risk to health, safety or fundamental rights appears it notifies the provider and the market surveillance authority immediately and suspends use of the system. Suspension is the part a monitoring plan usually lacks, so the plan names the person who can stop the system and the indicator that triggers it. AIG-021 carries the incident and reporting limb of the same paragraph.
Performance on the deployer's own population and input distribution is measured by the deployer. Retraining is the provider's escalation, reached through the AIG-032 change notification terms.
Art.26(6) binds both seats and sets a floor: the automatically generated logs under the deployer's control are kept at least six months, longer where Union or national law requires it. Art.12(3) adds the fields a deployer of a remote biometric identification system under Annex III point 1(a) has to be able to produce, the period of each use, the reference database, the input data that led to a match and the identification of the persons who verified the result. That extract row, EU-AI-Art.12.2, maps partial to this control since migration 063 with the four fields named as the gap, so the deployer's log extends the minimum record by them. Annex III point 1 is in practice a public-authority area, which is why the fields sit on this profile and not on the base. MON-003 holds the retention schedule.
Art.26(5) binds both seats. A serious incident is notified to the provider immediately. Where the deployer cannot reach the provider, the Art.73 route to the market surveillance authority applies to the deployer instead. That is the one place this seat files a report the library otherwise treats as the provider's, so the process names who makes the call that the provider is unreachable and what evidences it. AIG-018 carries the monitoring and suspension limb.
Art.26(2) binds both seats: oversight is assigned to natural persons who have the competence, the training and the authority to perform it, with the support resources to do so. Art.14(5) adds a step the provider designs and the deployer performs: no action or decision is taken on an identification result produced by a remote biometric identification system under Annex III point 1(a) unless at least two natural persons with the necessary competence, training and authority have separately verified and confirmed it. The extract row, EU-AI-Art.14.3, maps partial to this control since migration 063 with the two-person step named as the gap, so the oversight design states that step for any such system. HRS-013 carries the competence the persons need.
The mechanism is built by the provider. Naming who may invoke it, exercising it at intervals and recording whether the supplier was needed are the deployer's.
Art.5(1)(h) is the one prohibition whose exceptions only a public authority can reach: real-time remote biometric identification in publicly accessible spaces for law enforcement is prohibited except for locating victims of abduction or trafficking, preventing a specific and imminent terrorist threat or detecting and locating the perpetrator of a serious criminal offence. A body that could use one records against that entry which exception is relied on and, for each use, the four Art.5(2) conditions (the use confined to confirming the identity of the targeted individual, the situation and the consequences for the rights of everyone concerned weighed, the national law's temporal, geographic and personal limits applied, the Art.27 assessment and the Art.49 registration completed first), the Art.5(3) prior authorisation from a judicial or independent administrative authority with the 24-hour urgency clock and the stop and deletion on a refusal, and the Art.5(4) notification to the market surveillance authority and the data protection authority. Those three paragraphs are extract rows since migration 065 (EU-AI-Art.5.2 to 5.4), each partial on this control with the regime named as the gap; Art.5(5) to (7) bind the Member State and the Commission and are excluded. Art.5 binds use as well as placing on the market, which the base already states.
Pre-deployment bias evaluation is the provider's, obtained through AIG-034. Evaluation in production on the deployer's own population is the deployer's.
Obtain the provider's AI security evaluation summary (AIG-034). Testing of what the deployer builds on top is APP-005 and AIG-029.
Threshold calibration and validation logic are the provider's. The deployer sets the fallback in its own workflow, in the AIG-022 oversight design, using the thresholds the instructions for use give.
The use cases, the acceptable rate and the measured rate on the deployer's own data are the deployer's. The grounding mechanism may be a provider feature or the deployer's own retrieval layer.
The row is the deployer's for every integration that places its own or external content into a prompt. Where the provider's interface is used as shipped, the testing is the provider's (AIG-034 test summary).
Runtime detection and response on systems the deployer exposes to users are its own. The assessment of prohibited generation outcomes for each model placed on the market is the provider's.
The procurement assessment is where a public body obtains what both seats need. Art.25(4) fixes the information and assistance the provider owes, Art.25(1) states when the deployer's own changes make it the provider instead and the AIG-037 checks land here as records: the EU declaration of conformity obtained and the CE marking confirmed before the system is put into service. For this profile the vehicle is usually a public tender, so the terms are set once at award and this record is what shows they were. Binds both seats, because neither can complete its own duty without the provider's Art.13 information.
The deployer's evidence for most of this profile, on both seats. The instructions for use under Art.13(2) and (3) are what Art.26(1) measures use against, what the Art.27 seat draws the risk information at point (d) and the oversight description at point (e) from and what Art.26(9) means by the information the provider supplies for the data protection impact assessment. Obtained under the AIG-032 agreement and held against the inventory entry.
The base conditions this row on the risk class; here the class is settled by the profile's facets, so the row is required and the condition goes. Conformity assessment, the declaration under Art.47 and the marking under Art.48 stay the provider's. What this seat does is check them: the EU declaration of conformity is obtained and the CE marking confirmed before the system is put into service, both recorded in the AIG-032 assessment, which is the same check on either seat. A public body has no route to the declaration other than the tender, so the check belongs at award rather than at go-live.
The channel the Art.27 seat points at. Point (f) of the assessment asks for the measures to be taken if a risk materialises, including the internal governance arrangements and the complaint mechanisms. This control is the artefact that answers it. A report contesting an output routes to the oversight process under AIG-022 and to the Art.86(1) explanation route under AIG-016. The public body's statutory complaint, review and appeal routes run alongside and are not restated here.
Art.26(1) and Art.26(4) bind both seats and are the central duties of this seat at high risk. Art.26(1) requires use in accordance with the instructions for use and the appropriate technical and organisational measures to secure that use, so every entry in the use register sits inside the intended purpose the provider stated or carries an exception record. Art.26(4) applies where the deployer controls the input data: relevance and representativeness against the intended purpose are checked before use. For a public body the input is commonly its own administrative record, which makes the check a data quality question it owns and the provider cannot answer.
The deployer is the customer. It obtains the provider's statement on whether its inputs are used for training, exercises the opt-out and records the answer in the AIG-032 assessment.
Permission sets, approval of consequential actions and invocation logs for agents the deployer runs against its own systems are its own. Where the agent runtime is the provider's, enforcement is a provider feature and the deployer configures and records the grants.
The base conditions this row on the risk class; here the class is settled by the profile's facets, so the row is required and the condition goes. Corrective action and the authority request register under Art.20 and Art.21 stay the provider's. Three parts are this seat's and bind both of them: non-conformity is reported to the provider under Art.26(5), a withdrawal, disablement or recall notice is acted on and under Art.26(12) the logs the deployer holds are produced to a competent authority on request without being altered. The route by which those logs are produced is documented, because at a public body the request can arrive through its own supervisory chain as well as from the market surveillance authority.
The first of the two seats this profile is built on. Art.49(3) binds deployers that are public authorities, Union institutions, bodies, offices and agencies or persons acting on their behalf: before a high-risk Annex III system is put into service or used, the body registers itself, selects the system and registers its use in the EU database. Systems in the Annex III point 2 area are carved out and carry no filing, so the record states the carve-out rather than leaving the field empty. The provider's Art.49(1) registration of the system is a different filing on a different seat and sits on AIG-003, so one system carries two references. The filing is due from 2 December 2027 with the other Annex III duties: Art.49 sits in Chapter III Section 5 rather than Sections 1 to 3, but the registration duty attaches to a high-risk system when Chapter III applies to it (ADR-025; owner decision of 2026-09-15 on the S11 digest).
The second of the two seats. Art.27 binds deployers that are bodies governed by public law or private entities providing public services, before the first use of a high-risk Annex III system, with the Annex III point 2 area excluded. Art.27(1) fixes six elements: the deployer's processes the system will be used in, the period and frequency of intended use, the categories of natural persons and groups likely to be affected in that context, the specific risks of harm to those categories taking account of the information the provider gives under Art.13, the implementation of the human oversight measures according to the instructions for use and the measures to be taken if those risks materialise, including the internal governance arrangements and the complaint mechanisms. Art.27(3) requires the result to be notified to the market surveillance authority on the filled-out template referred to in Art.27(5), which the AI Office develops. Art.27(4) lets the deployer cross-reference the relevant sections of a data protection impact assessment instead of repeating them, so DAT-013 supplies part of the artefact and AIG-006 the rest. The provider inputs are obtained under AIG-032 and AIG-034. A further use in materially the same context relies on the assessment already performed. The Annex III points 5(b) and (c) arm of Art.27, creditworthiness and the pricing and risk assessment of life and health insurance, binds a deployer that is neither seat and stays on the base profile's conditional row.
The pipeline the deployer fine-tunes or evaluates on is its own. The providers training pipeline is evidenced through the providers documentation (AIG-034).
The memory policy, the review of its own entries and the response to a suspected poisoning are the deployer's for agents it runs against its own systems and data. Where the agent runtime and its memory store are the provider's, the scope enforcement, the validation before commit and the version history are provider features and the deployer configures them and records that it has (AIG-034 instructions for use).
Required on the base as well since the S13 benchmark (ADR-049 amendment, 2026-09-16); stated here because a public body's intake points are where a forged artefact produces an adverse decision about a person: identity evidence for a benefit or a permit, media submitted as evidence in a proceeding and, under Annex III point 1, biometric identification. The documented assessment the control opens with is the row's first artefact; a body whose assessment finds no intake point that relies on inbound media as evidence records that finding and the detection limb has nothing to attach to. Both seats: the assessment and the record of each disposition are the deployer's, the detection method and its measured rates come from the provider where the intake runs on a provider's product (AIG-034). The code is core rather than role-duty because no article imposes the detection on the seat; the row is an assurance judgement about where the harm lands.
HRS · Human Resources Security
Art.4(1) binds providers and deployers alike, so it binds both seats and it is live now rather than from 2 December 2027 (ADR-025). At a public body the groups it reaches are wider than the operators: the persons assigned oversight under AIG-022 and the officials who take the decisions the system informs, who are the ones an Art.86(1) explanation request reaches. Art.4(1) asks for measures to support the development of AI literacy and says in terms that no specific level has to be guaranteed for any individual, so the test is the training standard and who it covers, not a competence certificate.
DAT · Data Protection
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, key ownership and the behaviour on withdrawal are its own. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider and the deployer obtains the key ownership statement and the withdrawal test result under VND-004.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, the location record for that system is its own and is enforced by its own configuration. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the deployer obtains the provider's location record under VND-004 and reflects it in DAT-006 and DAT-015.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, the export interface and the retrieval window belong to the service it operates. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the export interface and the post-termination retrieval terms are obtained under VND-004 and BCM-010 so the exit plan can be exercised.
INF · Infrastructure & Cloud Security
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, isolation between its own tenants, environments and workloads is its own and INF-004 covers the boundary. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the isolation statement and the cross-tenant test summary are obtained under VND-004.
MON · Monitoring & Logging
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, the availability objective and the status channel for that service are its own. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the deployer holds the provider's service level objective and status channel and reviews them under VND-006.
VND · Vendor & Third-Party Risk
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, it owns the responsibility split it publishes to whoever consumes that service. Under cloud-saas or cloud-single-tenant the row is satisfied by the provider: the deployer receives the matrix under VND-004 and reads it against this profile so each inherited control has a named owner.
Condition: deployment_model in on-prem, hybrid, edge, on-device, embedded, air-gapped
Where the deployer runs the AI system on infrastructure it controls, the data a request could compel is in its own custody and its procedure covers receipt, legal review, narrowing, approval and the record end to end. Under cloud-saas or cloud-single-tenant the deployer is the customer the provider notifies, it obtains the provider's request-handling terms under VND-004, and its own procedure still covers the personal data it controls directly.
AIG · AI Governance
Condition: the system is used at a workplace
Art.26(7) binds a deployer that is an employer, before a high-risk system is put into use at the workplace: the workers' representatives recognised at that site and the affected workers are informed through the information and consultation route the organisation's agreements or the applicable employment rules set. A public authority is an employer like any other, so this clause binds neither of the two seats the profile is built on and the row stays conditional. The condition drops the risk-class clause the base carries, since every system in this profile is Annex III high-risk; the phrase left standing is the one the assess_scope evaluator reads.
GOV · Governance & Risk
A deployer is the customer in this relationship, so the supervisory access it needs is its provider's: contracted under VND-002, obtained with the service under VND-004 and reviewed under VND-006. Where the deployer supplies a service of its own to a regulated customer, the row is its own and reads as it does on saas-ai-provider.
APP · Application Security
The disclosure programme for the product is the provider's and is reviewed under VND-006. A deployer with internet-facing services of its own benefits from one; no framework in the profile requires it of a deployer.
AIG · AI Governance
The registry is the provider's. The deployer records the model versions in production against the AIG-003 inventory entry and the BCM-010 continuity entry and takes version and change notices under the AIG-032 agreement.
DAT · Data Protection
The deployer is the party switching, not the party executing the switch. BCM-010 and VND-008 hold its side: the exit plan over the services it buys and the offboarding of a departing supplier.
The deployer calls the retrieval interfaces rather than publishing them. Whether the provider's interfaces reach it on equal terms is a question it asks under VND-001 and VND-004.
VND · Vendor & Third-Party Risk
Exit and regulatory terms are what a provider owes the customers of a service it sells. An enterprise operating AI systems for its own business is the customer in that relationship, and the terms it reads are covered by VND-002 and VND-004. Where the deployer also supplies a service to external customers it holds the provider seat for that service and reads the row on saas-ai-provider.
The deployer exercises audit rights rather than granting them; VND-006 is where it reviews the suppliers it buys from. Where it supplies a service to external customers it holds the provider seat for that service.
The deployer reads the provider's subcontractor disclosure and objects through it under VND-002 and VND-003 rather than publishing one. Where it supplies a service to external customers, the disclosure and the hold on a change are its own and it reads the row on saas-ai-provider.
AIG · AI Governance
Art.17 binds providers of high-risk systems. A deployer that triggers Art.25 becomes the provider and moves to high-risk-provider-eu.
Art.22 and Art.54 bind providers established outside the Union. Where a non-EU provider has appointed a representative, the deployer records the contact details from the provider's documentation in its AIG-032 assessment.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
Published 2026-09-15