Twelve frameworks, one control library

A vendor that builds a cloud product with AI in it, runs it for many customers and places it on the market under its own name. This is the AICF library as written: every control, evidence record and question was drafted from this seat, so the profile marks every control as required apart from the four conformity and market-obligation controls that bind only a provider whose system falls in a high-risk or general-purpose class. It covers the security programme a SaaS company runs, the privacy duties it owes as a processor and as a controller, the AI governance of the systems it builds and the transparency duties that attach to generative features. The duties of the customer that deploys the product belong to enterprise-ai-deployer; the Chapter V duties of a general-purpose model provider belong to gpai-model-provider.

An organisation that procures AI systems built by others and operates them under its own authority, alongside the security programme it already runs. It keeps its own identity, data, incident, continuity and personnel controls, so the security domains apply to it as they would to any organisation. Its AI duties are the ones the EU AI Act, ISO/IEC 42001 and the NIST AI RMF place on the operator: use within the provider's instructions, input data relevance, assignment of human oversight, monitoring in use, retention of the logs the system generates, AI literacy and telling the people its decisions affect. Build-side controls such as training data, verification testing and technical documentation are marked satisfied by provider: the deployer's evidence is the documentation, test summary and instructions for use it obtains from the provider under AIG-032 and AIG-034, so a questionnaire shows the evidence to collect rather than a gap. A deployer that puts its own name on a high-risk system, substantially modifies it or changes its intended purpose becomes its provider under Art.25 and moves to a provider profile. A public body, and a deployer of a system that scores creditworthiness or prices life or health insurance risk, carries the fundamental rights impact assessment and the public register entry as conditional rows here rather than in a profile of its own. Rows a cloud provider discharges for its customers are marked satisfied by provider; where the deployer runs the system on infrastructure it controls, those rows are conditional on the deployment model and the duty is its own.

A provider that places a general-purpose AI model on the market and carries the Chapter V duties that come with it: model documentation and downstream information, a copyright policy and rights reservation compliance, the public summary of training content and, once a model is designated as carrying systemic risk, a systemic risk framework and acceptance determination, evaluation under standardised protocols, protection of the model weights and infrastructure and serious incident reporting to the AI Office, with the Safety and Security Model Report recommended. The statement is seeded from saas-ai-provider because an organisation that trains and offers a model runs the same security, privacy and governance programme, and re-judged where the seat differs: the high-risk conformity rows are out of scope for a model as such and the Art.54 authorised representative arm is conditional on establishment outside the Union. A provider that also serves its model through a product holds the provider role and saas-ai-provider alongside this profile (ADR-046).

The saas-ai-provider library read from the seat a high-risk classification gives it: a provider whose system falls in a high-risk class under Art.6 of Regulation (EU) 2024/1689, through Annex III or as a safety component of a product covered by an Annex I instrument. Nothing here replaces the base profile. The overlay states only what the classification changes or adds to a control the provider already runs, which is almost always a retention period, a documented artefact, a counterparty or a clock. What the classification changes is the standing of Chapter III Section 2: risk management, data governance, technical documentation, logging, transparency, human oversight and accuracy, robustness and cybersecurity become duties an authority can demand evidence of. The market procedures around them come with them, conformity assessment, the EU declaration of conformity, the CE marking, registration in the EU database, corrective action and the duty of information, post-market monitoring and serious incident reporting to the market surveillance authority. The profile is reached by risk class rather than chosen: an organisation holds it because a system it places on the market is classified high-risk. It composes with saas-ai-provider rather than replacing it. Deployment stays the base's, cloud SaaS and cloud single-tenant; a provider shipping a high-risk system on-premises, at the edge or embedded in a product is Phase U3 work and is not stated here. No new instrument arrives with the overlay, so the framework list is the base's and every article cited below was already extracted and mapped. Under Art.113 as amended by Regulation (EU) 2026/1744, Chapter III Sections 1 to 3 apply from 2 December 2027 for systems classified high-risk under Art.6(2) and Annex III and from 2 August 2028 for systems under Art.6(1) and Annex I (ADR-025). Art.111(2) gives a system used by a public authority that was placed on the market before its application date until 2 August 2030. Art.4 AI literacy and the Art.5 prohibitions bind already and do not wait on those dates.

The 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.

A provider of data processing services offering the service to customers in the Union, which is every IaaS, PaaS and SaaS vendor with an EU customer whatever its size or place of establishment. On top of the provider baseline it carries Chapter VI of Regulation (EU) 2023/2854: the duty to remove switching obstacles, the nine mandatory clauses of the switching contract, the notice, transitional and retrieval clocks, the abolition of switching charges on 12 January 2027, open interfaces free of charge and functional equivalence support. It also carries Art. 32, the first EU rule on a third-country demand for non-personal data held in the Union, together with the Art. 28 duty to publish which jurisdiction the infrastructure is subject to and what stops such a demand succeeding. The instrument is not about security, which is why most of it lands on controls the library does not yet have rather than on the ones it does. It is an overlay on saas-ai-provider and composes with it rather than replacing it.

A SaaS AI provider selling to EU financial entities: banks, insurers, investment firms, payment institutions, crypto-asset service providers and the rest of the Art. 2 list. DORA binds the customer, not the vendor, reaching the vendor through the Art. 30 contract every such customer must now sign. On top of the provider baseline this overlay carries the vendor side of Chapter V, Section I: the register data the customer collects, the pre-contractual diligence it runs, the contractual provisions of Art. 30(2) and (3), the audit and inspection rights it must be granted, the subcontracting conditions of the RTS on subcontracting and the transition period it exits through. It changes no control's applicability, because DORA adds nothing a provider can decline. What it changes is depth: nineteen controls acquire a contractual counterparty and an outside auditor. Four duties the library does not yet state are proposed in docs/s7-dora-proposals.md. The oversight framework that applies once the ESAs designate a provider critical is out of scope and tracked as a watch. One limit is recorded rather than closed: RTS 2024/1773 Art. 9(1) asks the customer to monitor confidentiality, integrity and authenticity indicators on an ongoing basis, and a multi-tenant provider cannot expose a per-customer confidentiality or authenticity indicator; see the MON-010 row.

The same SaaS AI provider, selling into United States healthcare. A vendor whose service creates, receives, maintains or transmits electronic protected health information on behalf of a covered-entity customer is a business associate under 45 CFR 160.103 and has been directly liable for the Security Rule since the 2013 Omnibus Rule, whatever its contract says. This overlay states what that liability adds to the base library rather than restating it: the specifications the rule names and enforces, the clocks and retention floors it fixes that no canonical control sets, and the contract terms that run upward from the vendor to its customer instead of downward to its suppliers. It is an overlay on saas-ai-provider and inherits every applicability that profile states. The covered entity's own duties, and the duties of a health care clearinghouse or a group health plan, are another seat and belong to a profile that does not exist yet; the five rows of the extract that state them carry exclude-scope dispositions rather than applicability here.

The saas-ai-provider library read from the seat NIS2 gives it: a cloud computing service provider that is an essential or important entity under Directive (EU) 2022/2555 and a relevant entity under Implementing Regulation (EU) 2024/2690. Nothing here replaces the base profile. The overlay states only what the two instruments add to a control the vendor already runs, which is almost always a clock, a threshold, an audience or a documented reason. The Implementing Regulation is directly applicable, so it binds a provider serving EU customers whether or not the Member State has finished transposing the Directive, and it is written at requirement level rather than as principles: the Annex enumerates the contents of each policy and the review that keeps it current. Three additions carry most of the weight. Incident reporting acquires a statutory sequence to a CSIRT, a 24-hour early warning, a 72-hour notification, an intermediate report on request, a final report within a month and a progress report where the incident is still running. Incident classification acquires external thresholds, 30 minutes of complete unavailability, one hour of limited availability reaching the lower of 5 % of Union users or one million, EUR 500 000 or 5 % of turnover, and exfiltration of a trade secret. Governance acquires a management body that approves the measures, is trained to assess them and is reported to directly. The identification of the entity as essential or important, the national transposing law and the Member State supervisory regime sit outside the overlay: they are establishment questions, not controls. The managed service provider and managed security service provider seat (Implementing Regulation Art. 10) is a second role in this profile's composition rather than a second overlay: a vendor that also operates, administers or monitors a customer's systems holds the managed-service-provider role. The INC-003, INC-005 and MON-010 notes state what Art. 10 adds for it (product owner, S8 overlay profile review, 2026-09-14). No row is conditional on the seat, because the Art. 7 duties stay required for every reader; the first control only that seat triggers will carry the condition.