AI Governance Operating Model: Centralized vs Federated vs Hybrid

Neither Regulation (EU) 2024/1689 nor ISO/IEC 42001 prescribes a centralized, federated or hybrid AI governance operating model. Both texts fix who holds each duty and whether responsibilities are assigned and communicated, and those fixed points limit how much authority can move to business units. The comparison below tests each model against them instead of against a generic speed-versus-control trade-off.

What the Binding Sources and Standards Leave Open on Structure

The AI Act, as amended by Regulation (EU) 2026/1744, allocates obligations to operators by role, principally provider and deployer. Its provisions name no committee, officer or reporting line. Article 26(2) of the consolidated AI Act text requires deployers of high-risk systems to assign human oversight to natural persons who have the necessary competence, training and authority, together with the necessary support. The provision specifies the qualities of the person, not the function that person sits in.

ISO/IEC 42001:2023 is a management system standard, and certification against it is voluntary. Clause 5.3 requires top management to ensure that responsibilities and authorities for relevant roles are assigned and communicated within the organization. Annex A includes a control objective on internal organization (A.3). Like the AI Act, the standard requires that roles exist and are communicated, and it does not prescribe an organization chart.

The NIST AI Risk Management Framework is intended for voluntary use. Its GOVERN function addresses policies, processes and accountability structures for AI risk management. NIST’s own page states that AI RMF 1.0 is being revised as part of the White House AI Action Plan, so any crosswalk to the framework should be revisited when a revised version is published.

Which Duties Attach to Which Role, and From When

The AI Act defines a provider and a deployer as a natural or legal person, public authority, agency or other body. A business unit is not one of those. The duty therefore sits with the legal entity acting in the role, and an operating model has to name an owner for each duty entity by entity. The table lists the duties most relevant to structure. The evidence column is editorial analysis of what an auditor could reasonably request.

Two rows constrain design more than the rest. Article 26(2) names qualities of a person, and Article 4 requires measures that take account of role and context. A policy issued from the center cannot satisfy either on its own, because the duty is met only when a competent individual is in fact assigned.

Centralized Governance: Uniform Evidence and a Competence Limit

A single accountable function gives an organization one evidence trail. It suits the duties that turn on a consistent decision, such as screening proposed uses against Article 5, keeping the system inventory, and holding one scope for an ISO/IEC 42001 management system with a single set of Clause 5.3 assignments. An auditor who asks who decided and on what basis receives one answer.

The limit sits in the duties that need domain competence. A central body can set the criteria for an oversight role and keep the register of assignments, but Article 26(2) requires that the assigned person actually has competence, training and authority for the system in use. The published sources reviewed do not quantify decision delay in central models, so the bottleneck often attributed to this structure is an editorial observation and not a sourced finding.

Federated Governance: The Legal-Entity Problem

Federation places ownership with the units that run the systems, which aligns with the contextual wording of Article 4 and with the domain competence Article 26(2) requires. The difficulty is the mismatch already noted: obligations attach to a legal entity in a provider or deployer role. If two units in one entity make inconsistent decisions, the entity holds the duty and bears the exposure.

ISO/IEC 42001 Clause 5.3 adds a second test, because assignments must be communicated and not only made. A federated model that leaves a duty with a unit lead who has not been told of it does not meet that clause on its face. Federation is defensible where a common evidence standard, set centrally, governs what every unit records. Without one, the organization holds many local records that cannot be compared.

Group Structures and the AI Office’s Exclusive Competence

The amended Article 75

Regulation (EU) 2026/1744 rewrote Article 75. Its recitals state that the AI Office should have exclusive competence over AI systems built on general-purpose AI models, not only where system and model come from the same provider but also where they are developed by providers forming part of the same undertaking. The recitals add that the personal scope extends to the providers of those systems and to their deployers within the same undertaking. The amended provision contains exceptions, so scope has to be tested against the text of the Regulation for each system.

The text also directs providers of high-risk systems that fall within the AI Office’s competence to report serious incidents to the AI Office, by derogation from Article 73. It provides for the AI Office to open an investigation where it has reasonable grounds to suspect non-compliance by a provider or deployer within Article 75(1).

Integrating AI risk into existing systems

The recitals of Regulation (EU) 2026/1744 describe Articles 8(2), 9(10) and 17(3) as allowing economic operators to integrate an assessment of AI-specific risks into existing risk and quality management systems. Article 27 as amended allows a deployer to cross-reference the relevant sections of a data protection impact assessment or incorporate parts of it, and provides for an AI Office template questionnaire. Editorial analysis: these provisions favor a structure in which a central function owns the AI-specific templates and criteria, while existing risk, quality and privacy functions run them.

Hybrid Governance: Allocating Decision Rights

A hybrid model is a decision-rights allocation, and its quality depends on how each decision is placed. The allocation below is editorial analysis built on the duty holders and dates already sourced, not a structure any instrument requires. The sources reviewed supply no numeric scoring scale for escalation, so triggers based on invented scores would have no citable basis. The AI Act’s own categories (prohibited practice, Annex III system, Article 50 transparency case, Article 25(1) trigger, Article 26(5) risk or serious incident) give defensible triggers.

Tuning the allocation by system class

A hybrid allocation does not have to be uniform across systems. The table below is editorial analysis showing how the allocation above can shift with Annex III exposure and Article 75 scope.

What the Central Function Has to Produce, and Where the Documentation Burden Sits

The sources reviewed give no headcount, budget or cost data for any operating model, so this section locates the maintenance burden and does not rank it by cost. Because duties attach to legal entities, a central function in a hybrid or centralized model has a minimum defined by outputs and not by size. Editorial analysis: it has to produce the duty register at legal-entity level, the system inventory with classification decisions, the evidence standard and templates that local units complete, and the regulator interface, which for a group inside Article 75(1) is a single channel to the AI Office. A function that produces less leaves some entity holding a duty with no owner or with evidence that cannot be compared with the rest of the group. The number of entity-level registers, communication records and channel operations has to be counted from the organization’s own numbers of entities, systems and assignees.

Regulation (EU) 2026/1744 extends simplified Article 17 quality management elements to SMEs without partner or linked enterprises. Editorial analysis: on that wording, a group entity that has linked enterprises should test its eligibility before assuming the simplified route, because group membership may take it outside the provision.

Boundary Controls: Role Conversion and Procurement Intake

Article 25(1) and the change of role

The Commission’s AI Act Service Desk text of Article 25 treats a distributor, importer, deployer or other third party as the provider of a high-risk AI system, subject to the provider obligations under Article 16, in three circumstances. The first is putting the party’s name or trademark on a high-risk system already placed on the market or put into service, without prejudice to contractual arrangements allocating the obligations otherwise. The second is a substantial modification to a high-risk system already on the market or in service, in such a way that it remains high-risk under Article 6. The third is modifying the intended purpose of an AI system, including a general-purpose AI system, that was not classified as high-risk, in such a way that it becomes high-risk under Article 6.

Where one of those circumstances occurs, the provider that initially placed the system on the market ceases to be its provider and must cooperate with the new provider. Article 25(2), as replaced by Regulation (EU) 2026/1744, provides that the cooperation and documentation hand-over duty does not apply where the initial provider has clearly specified that its system is not to be changed into a high-risk system. An organization that repurposes a system whose provider excluded that change cannot rely on a documentation hand-over from the provider.

Editorial analysis: the trigger events occur locally, in branding decisions, configuration changes and new use cases, while the legal consequence lands on the entity. A hybrid model therefore keeps the assessment of substantial modification and intended purpose with a central function and makes local reporting of change a condition of release.

Procurement intake as a control point

The deployer provisions reviewed for this article (Articles 25 and 26) contain no duty to verify a provider’s declaration of conformity. Article 26(1) does require deployers to use a high-risk system in accordance with the instructions for use accompanying it, so obtaining and retaining those instructions is a precondition of lawful use. Published summaries of ISO/IEC 42001 Annex A describe a control objective on third-party and customer relationships (A.10), covering supplier and customer responsibilities.

Editorial analysis: a gate before contract signature can record whether the organization will act as deployer or, through the Article 25(1) triggers, as provider. It can also record the provider’s documented intended purpose and instructions for use, and route any planned modification to the classification decision. Ownership splits naturally. The central function keeps the role determination and register, procurement runs the gate, and the business unit declares the planned use.

Escalation Paths: Incident Loops, Worker Information and Reporting Channels

From local detection to regulator notification

The Commission’s text of Article 26 requires deployers to monitor the operation of a high-risk system on the basis of the instructions for use and, where relevant, to inform providers in accordance with Article 72. Where a deployer has reason to consider that use in accordance with the instructions may result in a risk within the meaning of Article 79(1), it must without undue delay inform the provider or distributor and the relevant market surveillance authority, and suspend use. Where a deployer has identified a serious incident, it must immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities. If the provider cannot be reached, Article 73 applies by analogy.

The Commission’s text of Article 73 sets its own clock for the provider reporting path. For a widespread infringement or a serious incident as defined in Article 3, point (49)(b), the report must be made immediately and not later than two days after the provider or, where applicable, the deployer becomes aware of the incident. The provisions reviewed set no comparable internal deadline for deployers between local detection and central escalation, so the timing of those internal steps is a design choice and not a legal figure.

Worker information and internal reporting

Article 26(7) requires deployers who are employers to inform workers’ representatives and the affected workers, before a high-risk system is put into service or used at the workplace, that they will be subject to its use. That duty is one of information. Article 26(11) is separate: it requires deployers of Annex III systems that make or assist decisions about natural persons to inform those persons that they are subject to the system. The two notices have different audiences and can have different owners.

Neither duty creates a channel for reporting non-compliance. Article 87 provides that Directive (EU) 2019/1937 applies to the reporting of infringements of the AI Act and the protection of persons reporting them. Article 8 of that Directive requires Member States to ensure that private-sector legal entities with 50 or more workers establish internal reporting channels and follow-up procedures. Article 85 separately gives any natural or legal person the right to complain to a market surveillance authority. That right is external and does not replace an internal channel.

The Commission’s report on the Directive’s transposition states that Article 8(3) requires every private-sector legal entity with 50 or more workers to set up internal channels, and that a few Member States incorrectly allowed corporate groups to set up channels solely at group level. Editorial analysis: a centralized model cannot rely on one group channel to discharge each entity’s obligation, and any model needs a named owner for the channel and a defined hand-off from the channel to the incident loop above.

Where the entity-level channel meets the central incident loop

Three provisions meet at the hand-off. Article 9(1) of the Directive requires acknowledgment of a report within seven days, designation of an impartial person or department to follow it up, and feedback within three months. Article 16 of the Directive provides that the reporting person’s identity is not disclosed to anyone beyond the authorised staff members competent to receive or follow up on reports, without that person’s explicit consent. Article 26(5) of the AI Act requires a deployer that has identified a serious incident to inform the provider immediately.

Editorial analysis: the text produces three points of friction in a hybrid model. First, a central AI function is not automatically among the authorised staff under Article 16, so the hand-off protocol should pass the facts of a report without the reporter’s identity. Second, a seven-day acknowledgment cycle and an immediate notification duty run on different clocks, so the facts relevant to a possible serious incident should reach the evaluating function without waiting for the acknowledgment step. Third, where the channel sits with a compliance or human resources function and the incident loop sits with a central AI function, a written protocol should name who classifies a report as a potential Article 26(5) event.

The template below shows the fields of a hand-off protocol entry. Bracketed entries are placeholders. The time references come from Article 9(1) of the Directive and the sequence from Article 26(5); the field set itself is editorial.

Fictional format example. Every name, identifier and date below is invented to show how a completed entry reads. It does not describe a real report.

• Report reference and receiving entity: [Reference A-001]; Entity B, a subsidiary; 14 September
• Acknowledgment: 16 September, two days after receipt
• Designated follow-up: Compliance Officer, Entity B
• Facts passed: a high-risk recruitment system, possible rise in false negatives after a model update; no reporter identity included
• Classification: possible serious incident; decided by the central AI incident lead; 16 September
• Notification sequence started: 16 September, with the provider informed first
• Feedback due: three months after the acknowledgment date

Evidencing the Named Person and the Communicated Assignment Across Entities

Article 26(2) names four qualities for the person assigned to human oversight: competence, training, authority and support. The provision does not prescribe how to evidence them, and ISO/IEC 42001 Clause 5.3 requires assignments to be communicated without prescribing the record. Editorial analysis: the four qualities give a reviewer four things to look for, and a per-system assignment record can answer each.

• Assignment: the named person, the legal entity, the system and the date of assignment.
• Competence and training: a link between the person’s training record and the provider’s instructions for use for that system, since Article 26(1) makes those instructions the basis of use.
• Authority: a documented power to suspend use of the system, which corresponds to the suspension duty in Article 26(5).
• Support: the time, access and resources allocated to the role.
• Communication under Clause 5.3: per entity and per role, the date, method and recipient of the communication, with the recipient’s acknowledgment.

The template below shows the fields of a per-system assignment record. Bracketed entries are placeholders. The field set is editorial and follows the qualities named in Article 26(2), the instructions-for-use basis in Article 26(1), the suspension duty in Article 26(5) and the communication requirement in ISO/IEC 42001 Clause 5.3.

Fictional format example. Every name, identifier and date below is invented to show how a completed record reads. It does not describe a real system or person.

• System and legal entity: [System A], a recruitment ranking system; Entity B
• Placement or service date: a date before the Chapter III date of application, recorded for the Article 111(2) question
• Named person and assignment date: the HR operations lead; assigned on a recorded date
• Competence and training basis: a training record mapped to the sections of the provider’s instructions for use that cover override and suspension
• Authority: a written delegation authorizing suspension of the system
• Support: a recorded share of working time, plus access to the monitoring dashboard and the provider’s support channel
• Clause 5.3 communication: sent by email with a read receipt, acknowledgment logged under a reference
• Review date: six months after assignment

The models differ in who holds these records. In a federated model each entity produces them without a common format. In a hybrid model the central function sets the template and the criteria, and the entity produces the record, because the entity holds the duty. In a centralized model the central register aggregates them, but the competence itself still has to be evidenced for the individual in the business unit.

Running Parallel Processes and Handling Systems Already in Use

The calendar produces three live workstreams and one deferred one. Article 4 measures and Article 5 screening already apply, Article 50 applies from 2 August 2026, and the high-risk provisions follow later dates. Article 111 in the consolidated text, as replaced by Regulation (EU) 2026/1744, provides that the Regulation applies to operators of high-risk systems placed on the market or put into service before the date of application of Chapter III only if, from that date, those systems are subject to significant changes in their designs. A recital to the amending Regulation refers to significant changes in design or intended purpose. Providers and deployers of high-risk systems intended for use by public authorities are separately required to take the necessary steps to comply by 2 August 2030. New Article 111(4) gives providers of generative systems placed on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2).

Editorial analysis: three design points follow.

• Placement date. The date on which each system was placed on the market or put into service decides whether Article 111(2) applies, so the inventory has to record it.
• Change log. The Regulation uses “significant changes in design” in Article 111(2) and “substantial modification” in Article 25(1)(b). A change log should ask both questions for each change and should not treat them as the same test.
• Staged build. Owners for Articles 4, 5 and 50 need to be operating now, while the oversight register, incident sequence and role-determination process are built in stages before 2 December 2027.

Public-sector providers and deployers

For public-sector providers and deployers, three tracks run at once. Articles 4 and 5 already apply, and Article 50 applies from 2 August 2026. For high-risk systems placed on the market or put into service before the date of application of Chapter III, Article 111(2) applies the Regulation only if the system undergoes significant changes in design, but providers and deployers of systems intended for use by public authorities must in any case take the necessary steps to comply by 2 August 2030. On that wording, systems placed after the Chapter III date of application follow the Chapter III dates directly. Editorial analysis: the inventory therefore needs a field for public-authority use. The change log for a grandfathered public-authority system determines only whether obligations arrive earlier than 2030, and it does not remove the 2030 date. The live duties under Articles 4, 5 and 50 continue regardless of the high-risk track.

Worked Scenarios: Three Illustrative Allocations

The scenarios below are hypothetical illustrations, not descriptions of any organization. They apply only the provisions sourced above and contain no figures.

A multi-entity group with providers and deployers in one undertaking

Several legal entities act as provider or deployer, and the group’s systems fall within Article 75(1). The duty register runs per entity. The central function keeps the inventory, the classification decisions and the single channel to the AI Office. Each entity names its own Article 26(2) assignees and holds its own Clause 5.3 communication records. Each entity with 50 or more workers operates its own internal reporting channel, and the central function receives the facts of relevant reports under the hand-off protocol.

A pure deployer of procured systems

The organization has no Article 17 duty, so the central function can stay narrow: role determination and classification at the intake gate, the oversight competence criteria and the incident sequence. Business units name the Article 26(2) assignees and run Article 26(5) monitoring. Article 26(7) notices go through employer functions where the organization is the employer. The watch item is Article 25(1)(c): a business unit that repurposes a system moves the case out of this scenario.

An organization that rebrands or modifies systems

Article 25(1) makes the organization a provider whenever a trademark, substantial modification or purpose-change trigger applies to a high-risk system, so provider obligations under Article 16 enter the design. Central change assessment is a condition of release, and the change log feeds both the Article 25(1) and the Article 111(2) questions. Where the initial provider has excluded repurposing into a high-risk system, Article 25(2) as replaced removes its hand-over duty, so the organization builds its own documentation and plans for provider-side duties such as Article 17 quality management from the Annex III date.

Choosing a Model Against Verifiable Constraints

The selection below is editorial analysis. The criteria come from the sourced provisions above and do not depend on organization size claims or maturity scores.

• Legal entities in a provider or deployer role. A group with several such entities needs an entity-level duty register whichever model it adopts, and the number of entities raises the cost of a purely federated model.
• Provider or deployer exposure. Article 17 addresses providers of high-risk systems, and Article 26 addresses deployers. An organization that is only a deployer has no Article 17 duty and can concentrate its design effort on oversight assignment, incident notification and impact assessment.
• Procured versus modified systems. Where a system is procured, role determination sits at the intake gate. Organizations that rebrand, modify or repurpose a system carry the Article 25(1) exposure and need central change assessment.
• Annex III exposure. Articles 25, 26 and 27 apply to Annex III systems from 2 December 2027, which sets the date by which a competent overseer, an incident sequence and a role-determination process must be in place.
• Existing management systems. Because the recitals allow AI-specific risk to be integrated into existing risk and quality systems, an organization with mature systems has grounds to extend them and not to build a parallel structure.
• Relief for smaller providers. Regulation (EU) 2026/1744 lets SMEs without partner or linked enterprises comply with certain Article 17 elements in a simplified manner. A qualifying provider may not need the full central function a larger group would build.
• Group scope under Article 75. Where a system falls within the AI Office’s exclusive competence, a designated central regulator interface follows from the incident-reporting rule.

Dates That Set the Sequence for Governance Design

Regulation (EU) 2026/1744 deferred some obligations and left others in place, so the calendar has to be read provision by provision. The Annex III and Annex I dates were moved, while the prohibitions and the AI literacy duty already applied, and the general transparency date was not deferred.

Where Operating Model Decisions Go Wrong

• Reading the Omnibus as a general postponement. The deferral covers the high-risk provisions. Article 4, the prohibitions and Article 50 follow their own dates, so an organization that pauses its whole program on the strength of the 2027 date leaves live duties without an owner.
• Treating amended Article 4 as a per-person level. The amended text requires measures that support AI literacy and does not oblige providers or deployers to bring any individual to a specified level. Evidence should describe the measures and their fit to role and context.
• Equating ISO/IEC 42001 certification with AI Act conformity. The standard governs how an organization runs its management system, and certification is voluntary. It does not decide whether a given system meets the requirements for placement on the EU market.
• Assigning oversight by title. Article 26(2) refers to natural persons with competence, training and authority, plus support. A register listing a role without evidence of those qualities does not track the text.
• Naming a business unit as the duty holder. The provider and deployer definitions refer to persons and bodies, not to internal units, so the register has to run at legal-entity level.
• Treating deployer status as fixed. Under Article 25(1), rebranding, substantially modifying or repurposing a system can make the organization the provider. A structure with no control over those changes leaves that conversion unmonitored.
• Reading the Article 85 complaint right as an internal channel. Article 85 addresses complaints to market surveillance authorities. The internal channel obligation comes through Article 87 and Directive (EU) 2019/1937, and applies per legal entity.
• Treating systems already in use as exempt. Article 111(2) as replaced applies the Regulation to pre-existing high-risk systems that undergo significant changes in design, and sets a separate final date of 2 August 2030 for systems intended for use by public authorities. The protection is conditional, and a change log is what shows whether the condition has been met.

Why Duty Allocation Now Decides Whether an Operating Model Holds Up in an Audit

Auditors and supervisors can test an operating model against fixed provisions and dates, whichever label the organization gives it. The documentation below follows from the sourced provisions and is ordered by the dates in the table above.

1. Build a duty register at legal-entity level, recording the provider or deployer role of each entity and the named owner of each duty in the duty table.
2. Record ISO/IEC 42001 Clause 5.3 assignments with evidence that each was communicated to the person concerned, per entity and per role.
3. Record the placement or service date for each system and keep a change log that asks both the Article 111(2) and the Article 25(1)(b) question for each change.
4. Run a procurement intake gate that records role determination, the provider’s intended purpose and the instructions for use for each system.
5. Set a change-control rule requiring assessment of branding, modification and intended-purpose changes against Article 25(1) before release.
6. Keep an oversight register for Annex III systems that records each assignee’s competence and training, authority to suspend use, and support, ready before 2 December 2027.
7. Document the Article 26(5) notification sequence, with named owners for detection, evaluation and notification and internal time limits set against the Article 73(3) clock.
8. Name the owner of the internal reporting channel for each legal entity with 50 or more workers, and write a hand-off protocol that passes report facts to the incident loop without the reporter’s identity.
9. Set the impact assessment process so that it cross-references data protection impact assessments, and adopt the AI Office questionnaire template once it is published.
10. Test each group entity against the amended Article 75 and, where a system is in scope, designate one channel for incident reporting and regulator requests.
11. Update prohibited-practice screening criteria and Article 50(2) marking work before 2 December 2026.
12. Review the NIST AI RMF crosswalk when NIST publishes the revised framework.