EU AI Act Art.97: Committee Procedure (Comitology) — Implementing Acts, Regulatory Change Timelines, and Developer Compliance Strategy (2026)

Art.96 mandates Commission guidelines for practical implementation. Art.97 governs how the Commission's implementing acts — operational decisions that affect developers directly — actually get made. Between the static regulation text and your running AI system sits a machinery of committees, opinions, and publication timelines that determines when regulatory changes arrive, how fast they apply, and what recourse exists.

Most AI Act commentary ignores Art.97. That is a mistake for compliance professionals. The difference between an implementing act (Art.97) and a delegated act (Art.71) is not procedural trivia — it determines lead time, Parliamentary oversight level, developer consultation windows, and whether emergency changes can take effect without any committee vote. Understanding this machinery is the difference between reactive fire-fighting and proactive regulatory horizon scanning.

What Article 97 Actually Says

Article 97 is a three-paragraph comitology provision that establishes the committee assisting the Commission in adopting implementing acts under the AI Act.

Article 97(1) — The Committee Establishment:

The Commission shall be assisted by a committee. That committee shall be a committee within the meaning of Regulation (EU) No 182/2011.

This creates the AI Act's standing committee under Regulation (EU) No 182/2011 — the standard EU framework for delegating implementing power to the Commission while maintaining Member State oversight. The committee consists of representatives of Member States (typically ministry-level civil servants and NCA representatives) chaired by the Commission. It is a permanent body, not an ad-hoc panel.

Article 97(2) — The Examination Procedure:

Where reference is made to this paragraph, Article 5 of Regulation (EU) No 182/2011 shall apply. Where the committee delivers no opinion, the Commission shall not adopt the draft implementing act and the third subparagraph of Article 5(4) of Regulation (EU) No 182/2011 shall apply.

Article 5 of Regulation 182/2011 is the examination procedure — the standard mechanism for politically sensitive implementing acts. Three outcomes are possible:

• Positive opinion (simple majority of Member States): Commission may adopt the implementing act
• Negative opinion (qualified majority of Member States against): Commission cannot adopt; must submit to an Appeal Committee or revise
• No opinion (no majority for or against): Commission cannot adopt under Art.97(2)'s specific carve-out — this is stricter than the default Art.5(4) outcome, which would permit adoption in most cases

The no-opinion block is a deliberate legislative choice. When Member States are divided on an AI Act implementing act, the Commission cannot push through without resolving the deadlock. This gives smaller Member States meaningful veto leverage on operational AI governance decisions.

Article 97(3) — The Urgency Procedure:

Where reference is made to this paragraph, Article 8 of Regulation (EU) No 182/2011, in conjunction with Article 5 thereof, shall apply.

Article 8 of Regulation 182/2011 allows the Commission to adopt immediately applicable implementing acts without waiting for a committee opinion when duly justified urgency grounds exist. The implementing act then goes to the committee within 14 days. If the committee delivers a negative opinion, the implementing act is repealed — but it was already in force in the interim.

The urgency procedure matters for AI Act compliance because it is the mechanism for rapid regulatory responses to newly discovered systemic risks. If the AI Office identifies a GPAI model category requiring immediate new obligations, Art.97(3) in conjunction with Art.8 of Regulation 182/2011 is the legal pathway for emergency action before the committee has formally approved.

The Committee Composition and Working Process

The Art.97 committee is structured as follows:

The committee operates on a rotating presidency model for subgroup work. Member States typically send technical experts from their designated NCA (Art.57) or the competent ministry. The Scientific Panel (Art.61) may provide input but is not a committee member.

Working cadence:

• Regular meetings: approximately 4–6 times per year
• Emergency sessions: triggered by Art.97(3) urgency procedures
• Written consultation: for non-controversial administrative implementing acts
• Subgroup meetings: technical working groups on specific implementing act packages

Art.97 vs Art.71: The Critical Distinction for Developers

The AI Act uses two mechanisms for Commission-level regulatory change: delegated acts (Art.71) and implementing acts (Art.97). Developers need to understand the difference because the oversight level, timeline, and correction mechanisms differ fundamentally.

Which AI Act Provisions Use Each Mechanism

Delegated Acts (Art.71) — substantive regulatory scope:

• Art.6(6): List of standalone AI systems not posing high risk (significant classification impact)
• Art.7(1)/(2): Amending Annex I (AI definition) and Annex III (high-risk categories)
• Art.51(2): Modifying the GPAI systemic risk threshold (currently 10^25 FLOPs)
• Art.52(4): Extending transparency obligations to additional AI system types
• Art.53(3): Updating GPAI provider obligations for systemic risk models
• Art.97(4): Commission may extend the 5-year delegation

Implementing Acts (Art.97 committee) — operational and procedural:

• Specific GPAI model systemic risk designations (Art.51(3))
• Templates for technical documentation and declarations of conformity
• Formats for NCA notifications and cooperation procedures
• Rules for Union testing infrastructure access (Art.74(12))
• Specific standardisation mandates to ESOs
• Union database registration procedures (Art.60)
• Scientific Panel composition and procedural rules (Art.61(11))

The practical rule: if a change redefines whether your AI system is high-risk, that is a delegated act. If it changes how you fill out the form confirming your AI system is high-risk, that is an implementing act.

Regulatory Change Velocity: What Developers Must Track

The committee procedure determines the minimum timeline between a regulatory problem being identified and a binding response reaching developers. Understanding this velocity is essential for compliance planning.

Normal implementing act timeline:

1. AI Office or Commission identifies need → 4–8 weeks for internal draft
2. Commission proposes to committee → committee opinion typically within 4 weeks
3. Legal finalization and translation → 4–6 weeks
4. Publication in Official Journal → implementing act enters into force
5. Transition period (if any) → varies, sometimes immediate

Total: 3–5 months minimum for a standard implementing act

Urgency implementing act timeline (Art.97(3)):

1. AI Office identifies systemic risk requiring immediate action → Commission prepares urgency justification
2. Commission adopts immediately applicable implementing act → enters into force on publication day
3. Committee review within 14 days → if negative opinion, act repealed

Total: Days to 2 weeks before binding requirements apply

For GPAI model providers specifically, the urgency pathway is the high-risk scenario. An AI Office finding that a previously uncategorized GPAI model poses systemic risk can trigger an Art.97(3) urgency implementing act — adding your system to the systemic risk list with obligations effective immediately.

Delegated act timeline (Art.71) — for comparison:

1. Commission drafting and stakeholder consultation → 3–6 months
2. European Parliament and Council 3-month scrutiny window → may extend to 6 months
3. Publication in Official Journal → act enters into force
4. Transition period (typically 6–24 months for substantive changes)

Total: 12–30 months for a full delegated act amendment

The velocity asymmetry is significant. Developers should maintain separate monitoring tracks:

• Short-horizon (0–6 months): committee agenda, urgency measures, GPAI model list updates
• Medium-horizon (6–18 months): delegated act scrutiny periods, Annex I/III amendment proposals
• Long-horizon (18–36 months): Commission review cycles, Art.84(1) evaluation reports

CLOUD Act Regulatory-Change Velocity Implications

The Art.97 committee procedure has a direct CLOUD Act dimension. US-jurisdiction infrastructure faces a structural disadvantage when implementing acts create new data localization or transfer requirements:

US hyperscaler scenario:

• AI Office identifies cross-border training data risk
• Commission adopts urgency implementing act specifying EU-only storage for specific model categories
• Act enters into force within days
• Developers on US infrastructure face immediate non-compliance until migration

EU-native infrastructure scenario:

• Same implementing act applies
• Developers already operating on EU-sovereign infrastructure remain compliant by default
• No emergency migration required; operational continuity maintained

The Art.97 urgency procedure is precisely the mechanism that can impose overnight data sovereignty requirements. Developers who treat CLOUD Act risk as a theoretical concern have not fully modeled the Art.97(3) urgency scenario.

For sota.io-hosted AI systems, the EU-native infrastructure positioning is a direct compliance hedge against Art.97(3) emergency measures targeting cross-border data flows for high-risk or GPAI model training and inference.

Python ComitologyTracker: Monitoring the Regulatory Pipeline

The following implementation provides a lightweight framework for tracking implementing act proposals and entry-into-force dates across the AI Act's regulatory pipeline.

from dataclasses import dataclass, field
from datetime import date, timedelta
from enum import Enum
from typing import Optional

class ImplementingActType(Enum):
    STANDARD = "standard"       # Art.97(2) examination procedure
    URGENCY = "urgency"         # Art.97(3) immediately applicable
    DELEGATED = "delegated"     # Art.71 (not Art.97 but tracked together)

class ActStatus(Enum):
    PROPOSAL = "proposal"
    COMMITTEE_REVIEW = "committee_review"
    COMMITTEE_OPINION_POSITIVE = "committee_opinion_positive"
    COMMITTEE_OPINION_NEGATIVE = "committee_opinion_negative"
    COMMITTEE_NO_OPINION = "committee_no_opinion"
    PUBLISHED = "published"
    IN_FORCE = "in_force"
    REPEALED = "repealed"

@dataclass
class ImplementingAct:
    reference: str
    title: str
    act_type: ImplementingActType
    legal_basis: str             # e.g. "Art.51(3)", "Art.6(6)"
    status: ActStatus
    proposal_date: Optional[date] = None
    committee_meeting_date: Optional[date] = None
    oj_publication_date: Optional[date] = None
    entry_into_force_date: Optional[date] = None
    transition_period_days: int = 0
    affects_high_risk: bool = False
    affects_gpai: bool = False
    affects_prohibited: bool = False
    developer_action_required: str = ""
    notes: str = ""

    @property
    def compliance_deadline(self) -> Optional[date]:
        if self.entry_into_force_date:
            return self.entry_into_force_date + timedelta(days=self.transition_period_days)
        return None

    @property
    def days_until_compliance(self) -> Optional[int]:
        deadline = self.compliance_deadline
        if deadline:
            return (deadline - date.today()).days
        return None

    @property
    def is_urgency_risk(self) -> bool:
        return (
            self.act_type == ImplementingActType.URGENCY
            and self.status in (ActStatus.PUBLISHED, ActStatus.IN_FORCE)
            and (self.affects_gpai or self.affects_high_risk)
        )

class ComitologyTracker:
    def __init__(self):
        self.acts: list[ImplementingAct] = []

    def add_act(self, act: ImplementingAct) -> None:
        self.acts.append(act)

    def get_active_acts(self) -> list[ImplementingAct]:
        return [a for a in self.acts if a.status == ActStatus.IN_FORCE]

    def get_pipeline_acts(self) -> list[ImplementingAct]:
        pipeline_statuses = {
            ActStatus.PROPOSAL,
            ActStatus.COMMITTEE_REVIEW,
            ActStatus.COMMITTEE_OPINION_POSITIVE,
        }
        return [a for a in self.acts if a.status in pipeline_statuses]

    def get_urgency_alerts(self) -> list[ImplementingAct]:
        return [a for a in self.acts if a.is_urgency_risk]

    def get_compliance_horizon(self, days: int = 180) -> list[ImplementingAct]:
        cutoff = date.today() + timedelta(days=days)
        return [
            a for a in self.acts
            if a.compliance_deadline and a.compliance_deadline <= cutoff
        ]

    def compliance_summary(self, system_type: str = "high_risk") -> dict:
        relevant = [
            a for a in self.acts
            if (system_type == "high_risk" and a.affects_high_risk)
            or (system_type == "gpai" and a.affects_gpai)
            or (system_type == "any")
        ]
        return {
            "system_type": system_type,
            "active_obligations": len([a for a in relevant if a.status == ActStatus.IN_FORCE]),
            "pipeline_count": len([a for a in relevant if a.status in {
                ActStatus.PROPOSAL, ActStatus.COMMITTEE_REVIEW
            }]),
            "urgency_active": len([a for a in relevant if a.is_urgency_risk]),
            "next_compliance_deadline": min(
                (a.compliance_deadline for a in relevant if a.compliance_deadline),
                default=None
            ),
            "developer_actions": [
                a.developer_action_required for a in relevant
                if a.developer_action_required and a.status == ActStatus.IN_FORCE
            ],
        }


# Example: Track current implementing act pipeline
tracker = ComitologyTracker()

# GPAI systemic risk model list — first designation expected 2025-2026
tracker.add_act(ImplementingAct(
    reference="COM/2025/xxx-systemic-risk-list",
    title="List of GPAI models posing systemic risk (first designation)",
    act_type=ImplementingActType.STANDARD,
    legal_basis="Art.51(3)",
    status=ActStatus.PROPOSAL,
    proposal_date=date(2025, 9, 1),
    affects_gpai=True,
    developer_action_required=(
        "If your GPAI model may be in scope: prepare adversarial testing plan "
        "(Art.55(1)(a)), incident reporting procedures (Art.55(1)(b)), "
        "and cybersecurity framework (Art.55(1)(c)) before designation."
    ),
))

# Declaration of conformity template — harmonised format
tracker.add_act(ImplementingAct(
    reference="COM/2025/xxx-doc-template",
    title="Template for EU Declaration of Conformity for high-risk AI systems",
    act_type=ImplementingActType.STANDARD,
    legal_basis="Art.48(3)",
    status=ActStatus.COMMITTEE_REVIEW,
    affects_high_risk=True,
    developer_action_required=(
        "Prepare DoC draft using current Art.48(2) requirements. "
        "Update to official template once published to avoid NCA rejection."
    ),
))

summary = tracker.compliance_summary("high_risk")
print(f"Active obligations: {summary['active_obligations']}")
print(f"Pipeline items: {summary['pipeline_count']}")
print(f"Actions required: {summary['developer_actions']}")

Art.96 and Art.97 as a Governance Stack

Art.96 (Commission guidelines) and Art.97 (implementing acts via committee) form an overlapping governance infrastructure. Their relationship is sequential:

1. Art.96 guidelines set interpretive principles — what high-risk means in practice, how Art.5 prohibitions apply, SME compliance pathways. These are soft law: authoritative but not legally binding in the same sense as the regulation text.

2. Art.97 implementing acts set operational requirements — which specific GPAI models are on the systemic risk list, what technical documentation templates look like, how NCA cooperation procedures work. These are hard law: legally binding from the date of entry into force.

3. Art.71 delegated acts change the regulation's substantive scope — new Annex III categories, modified GPAI thresholds, extended transparency obligations. These are the highest-stakes regulatory changes; they require the longest lead time and highest oversight.

For compliance planning, developers should maintain a three-layer monitoring posture:

Layer 1 — Art.96 guidelines monitoring (ongoing):

• Subscribe to Commission DG CNECT AI Act implementation publications
• Monitor EUR-Lex under AI Act (Regulation 2024/1689) for associated documents
• AI Office publications at digital-strategy.ec.europa.eu

Layer 2 — Art.97 implementing act monitoring (monthly):

• Committee meeting agendas and outcomes (published via EU Register of Comitology)
• Official Journal Category C3 — AI Act implementing measures
• Art.51(3) GPAI model list updates (affects GPAI providers directly)

Layer 3 — Art.71 delegated act monitoring (quarterly):

• European Parliament Committee on Internal Market (IMCO) — scrutiny activities
• Council of the EU working party agendas on digital affairs
• Commission Work Programme annual publication (October each year)

Developer Checklist: Comitology-Ready Compliance Planning

1. Identify your implementing act exposure: Determine which Art.97 provisions apply — GPAI model list (Art.51(3)), DoC templates (Art.48), technical documentation formats (Art.11), or sector-specific procedural rules.

2. Establish a regulatory monitoring cadence: Set up monthly checks of the EU Comitology Register (https://eur-lex.europa.eu/comitology) filtered for AI Act implementing acts.

3. Subscribe to EUR-Lex AI Act alerts: Configure email alerts for new publications under Regulation (EU) 2024/1689 to catch implementing act publications immediately.

4. Monitor AI Office publications: Bookmark the AI Office homepage and subscribe to its newsletter for early-warning of GPAI-related implementing act proposals.

5. Track the GPAI systemic risk list (Art.51(3)): If you develop or deploy GPAI models, monitor the list for new designations that would trigger full Art.55 obligations (adversarial testing, incident reporting, cybersecurity framework).

6. Maintain a template-update process: When DoC templates (Art.48) or technical documentation formats are adopted as implementing acts, your documentation pipeline must update within the act's transition period.

7. Model urgency risk for GPAI providers: If you provide a GPAI model near the 10^25 FLOPs threshold, document your model's compute count and maintain Art.55-ready preparations in case of Art.97(3) emergency designation.

8. Review NCA cooperation format implementing acts: NCAs use harmonised formats for information requests (Art.58) and coordinated testing (Art.74). Implement these formats to avoid procedural delays in enforcement interactions.

9. Track Art.71 vs Art.97 distinctions in Commission work programme: Distinguish between implementing act proposals (6-month horizon) and delegated act proposals (18-month horizon) when planning compliance roadmap milestones.

10. Build implementing act review into QMS cycles (Art.9): Your risk management system should have a documented process for reviewing new implementing acts and updating procedures accordingly.

11. Prepare Art.6(6) standalone AI system list monitoring: If you claim exemption from high-risk classification under Art.6(3), monitor delegated acts under Art.6(6) for the official positive list of not-high-risk systems that could validate or undercut your classification.

12. Archive all implementing acts affecting your system: Maintain a compliance document archive that includes every implementing act relevant to your AI system, with entry-into-force dates and your implementation responses.

13. Document classification rationale against Art.96 guidelines: Align your Art.6 classification documentation with published Commission Art.96 guidance — this is what inspectors will reference.

14. Plan for no-opinion outcome: Understand that under Art.97(2)'s stricter no-opinion rule, contested implementing acts stay blocked until resolved — compliance timelines may extend beyond initial estimates if committee deadlock occurs.

15. Consider EU-native infrastructure for urgency resilience: Art.97(3) urgency acts can impose overnight data sovereignty requirements. EU-native infrastructure (EU-sovereign PaaS) eliminates migration risk under urgency scenarios.

16. Track Scientific Panel involvement: Art.61 Scientific Panel provides input on GPAI model evaluations; their findings feed implementing act proposals (Art.97) and AI Office actions (Art.62). Monitor Scientific Panel publications.

17. Register for Commission stakeholder consultations: While developers are not committee members, the Commission occasionally consults industry on implementing act drafts. Monitor Commission consultation portals to participate.

18. Assess cross-regulation implementing act interactions: AI Act implementing acts may reference NIS2, GDPR, and CRA procedural formats. Track whether NIS2 (NIS2 Art.23 incident notification formats) or GDPR implementing measures affect AI Act compliance documentation.

19. Incorporate comitology monitoring into legal counsel retainer scope: Ensure your legal counsel's scope explicitly includes tracking Art.97 implementing act proposals and advising on transition period compliance timelines.

20. Test urgency response procedures annually: Simulate an Art.97(3) urgency designation scenario — if your GPAI model appeared on the systemic risk list tomorrow, could you achieve Art.55 compliance within 6 months? Document gaps and remediation timeline.

See Also

• EU AI Act Art.98: Exercise of the Delegation — Delegated Acts, 5-Year Review Cycle, and Parliamentary Scrutiny — The Art.98 delegation framework that governs how the Commission exercises the delegated powers Art.97's committee procedure sits alongside
• EU AI Act Art.96: Commission Guidelines for AI Implementation — SME Compliance Pathways
• EU AI Act Art.71: Exercise of Delegation — Commission Delegated Acts Mechanism for Developers (2026)
• EU AI Act Art.51: GPAI Model Classification and Systemic Risk Designation — Developer Guide (2026)
• EU AI Act Art.55: AI Office Evaluation and Enforcement of GPAI Models — Developer Guide (2026)
• EU AI Act Art.61: Scientific Panel of Independent Experts — GPAI Evaluation and Systemic Risk Assessment (2026)