Here is the mistake I watched three teams make this spring. The trade press ran headlines that the EU AI Act high-risk rules slipped to December 2027, and everyone exhaled and moved the compliance work to next year. That reading is half right and expensive. The high-risk timetable did move. The obligations that already applied to general-purpose models, and the transparency rules that hit this August, did not. If you shipped a chatbot on Granite last quarter, your deadline is weeks away, not eighteen months out.

The EU AI Act is the European Union regulation that classifies AI systems by risk and attaches duties to each class. It became law in 2024 and applies in waves. This part is the readiness map: which wave catches your system, what each wave demands, what the fines actually are, and where watsonx.governance turns that from a spreadsheet of dread into an evidence pack you can hand an auditor.

Why an EU law reaches a model you built in Texas

The Act binds you on effect, not on address. Article 2 pulls in providers that place an AI system on the EU market and providers or deployers whose system output is used in the EU, regardless of where the company sits. A provider is whoever develops a system or model and puts their name on it. A deployer is whoever uses it under their own authority in a professional setting. If your SaaS answers a support ticket for a customer in Dublin, the output is used in the EU and you are in scope. Hosting the model in us-east does not change that.

This is the same extraterritorial move GDPR made, and legal teams that lived through GDPR recognise it on sight. The practical consequence: you cannot scope your way out by geoblocking a login page. You have to look at where the answers land. That single fact decides whether the rest of this article is your problem.

Four risk tiers, and where generative AI lands

The Act sorts systems into four tiers, and your duties follow the tier, not the technology. Most generative AI features are not high risk. They are transparency risk, which is a much lighter load. The trap is the small number of use cases that Annex III names as high risk: hiring and worker screening, credit scoring, biometric identification, essential-service eligibility, and a handful more. Put a Granite model behind a resume-ranking screen and the model did not change, but your obligations jumped two tiers.

Table 1. Risk tiers with the deadline each carries after the 2026 Digital Omnibus. High-risk standalone systems under Annex III moved from August 2026 to December 2027.

What GPAI providers must ship right now

A general-purpose AI model, GPAI in the Act, is a model trained on broad data that can do many tasks, which is most foundation models including Granite. If you only consume Granite through watsonx.ai, IBM is the GPAI provider and carries these duties. The moment you fine-tune a base model and place your version on the EU market under your own name, you can become a provider of that model yourself. That is the line most teams cross without noticing.

The GPAI obligations under Article 53 are concrete. Keep technical documentation covering architecture, training process, and evaluation. Give downstream builders enough documentation to use the model responsibly. Publish a summary of the training data content using the AI Office template. Put a policy in place to respect EU copyright, including text-and-data-mining opt-outs. These applied from August 2025, and the penalties attach from August 2026. IBM ships model cards and documentation for the Granite family precisely so you inherit that paperwork instead of writing it. Fine-tune, and you own the delta.

My recommendation here is blunt. If you can meet your quality bar on stock Granite without fine-tuning, do that, and keep IBM as the model provider of record. Fine-tune only when a measured gap justifies it, because the tuning that buys you a few points of accuracy also buys you a provider obligation you now have to document. That trade is worth naming before the training job starts, not after.

Provider or deployer, and why the label decides your work

Most enterprises are deployers, not providers, and deployer duties are lighter but real: use the system inside its intended purpose, keep human oversight, hold onto logs, and inform people where the Act requires it. Providers carry the heavy end: the conformity assessment, the technical file, the registration. The reason the label matters is that one design decision can flip it. Wrap a provider system in your own branding, or change its intended purpose, and you inherit provider duties. The flow below is the triage I run on every new AI feature before it ships.

flowchart TD
  A[New AI feature] --> B{Did you build or fine tune the model?}
  B -->|Yes, under your name| C[Provider role]
  B -->|No, you only deploy it| D[Deployer role]
  C --> E{General purpose model?}
  E -->|Yes| F[GPAI duties: tech docs, training summary, copyright policy]
  E -->|No| G{High risk use case in Annex III?}
  D --> G
  G -->|Yes| H[High risk duties by Dec 2027: risk mgmt, logging, oversight, conformity]
  G -->|No| I{User facing chat or synthetic media?}
  I -->|Yes| J[Article 50 transparency by Aug 2026]
  I -->|No| K[Minimal risk: voluntary codes]

How large are the fines, really?

Article 99 sets three penalty bands, and each is the higher of a flat cap or a percentage of global annual turnover, so the bigger the company, the more the percentage bites. Banned practices cost up to 35 million euro or 7 percent. Breaching most other obligations, including high-risk and transparency duties, costs up to 15 million or 3 percent. Giving regulators incorrect or misleading information costs up to 7.5 million or 1 percent. Because the fine tracks turnover, a large enterprise is exposed to a number no flat cap would ever reach.

Table 2. Article 99 penalty bands. The fine is the higher of the cap or the percentage, so at 500M turnover the percentage and the flat cap happen to match.

watsonx.governance and the EU AI Act accelerators

This is where the IBM stack earns its keep, and it is the reason a regulated shop picks watsonx over a raw model endpoint. watsonx.governance ships regulatory accelerators, which are prebuilt control templates mapped to the EU AI Act, NIST AI RMF, and ISO 42001. Instead of writing controls from a blank page, you start from a template that already lists what the Act asks for and tracks whether each control is met. The AI Risk Atlas, IBM Research work that catalogues AI risks, feeds a Risk Identification questionnaire so a use case gets scored against a known library rather than a reviewer memory.

Two pieces do the evidence work. AI factsheets capture model facts across the lifecycle, from which foundation model you used through prompt templates and evaluation results, which is exactly the technical documentation the Act wants. The Model Risk Evaluation Engine, added with IBM Research, scores foundation models against Risk Atlas dimensions so you can compare candidates before you deploy and record why you chose one. For runtime safety, Granite Guardian screens prompts and responses for harmful content, jailbreaks, and ungrounded answers, which I covered in Part 10. The governance mechanics themselves live in Part 19, so treat this part as the regulatory layer sitting on top of that.

Build an EU AI Act obligations check in code

Before any of this reaches a governance console, I like a small function that turns a system description into its obligations and deadline. It runs anywhere Python runs, it forces the team to name the role and tier out loud, and it doubles as a check you can drop into CI so a misclassified system fails the build. Here is the core of it.

from dataclasses import dataclass

@dataclass
class System:
    role: str          # provider or deployer
    is_gpai: bool      # a general purpose model you placed on the market
    risk_tier: str     # prohibited, high, transparency, minimal
    eu_turnover: float # global annual turnover in euro

DEADLINES = {
    'prohibited':   'in force since 2025-02-02',
    'gpai':         '2025-08-02, penalties from 2026-08-02',
    'transparency': '2026-08-02',
    'high':         '2027-12-02',   # Annex III standalone, per Digital Omnibus
    'minimal':      'no deadline, voluntary',
}
CAP = {'high': (0.03, 15_000_000), 'transparency': (0.03, 15_000_000),
       'gpai': (0.03, 15_000_000), 'prohibited': (0.07, 35_000_000),
       'minimal': (0.0, 0)}

def obligations(s: System):
    if s.risk_tier == 'prohibited':
        return {'status': 'STOP', 'why': 'Article 5 bans this use'}
    duties = []
    if s.is_gpai and s.role == 'provider':
        duties.append('GPAI: technical docs, training-data summary, copyright policy')
    if s.risk_tier == 'high':
        duties.append('High risk: risk mgmt, logging, human oversight, conformity')
    if s.risk_tier == 'transparency':
        duties.append('Article 50: disclose AI, label synthetic media')
    key = s.risk_tier if s.risk_tier in CAP else 'minimal'
    if key == 'minimal' and s.is_gpai:
        key = 'gpai'
    pct, flat = CAP[key]
    return {
        'status': 'ACT',
        'duties': duties or ['minimal risk: voluntary codes'],
        'deadline': DEADLINES.get(s.risk_tier, DEADLINES['minimal']),
        'max_fine_eur': round(max(pct * s.eu_turnover, flat)),
    }

if __name__ == '__main__':
    from pprint import pprint
    pprint(obligations(System('deployer', False, 'high', 500_000_000)))

Expected output:

{'status': 'ACT',
 'duties': ['High risk: risk mgmt, logging, human oversight, conformity'],
 'deadline': '2027-12-02',
 'max_fine_eur': 15000000}

The failure mode is the one that matters, and the code will not save you from it. If you pass risk_tier as minimal for a hiring screen that Annex III actually lists as high risk, the function returns voluntary codes and a zero fine, and you sail past the conformity work you owed. The logic is sound; the classification is the risk. That is precisely why the Risk Identification questionnaire in watsonx.governance exists, and why a human, not a default argument, should set the tier.

Three ways teams misread their own tier

Almost every misclassification I see falls into one of three patterns, and each one lands a system in a lighter tier than it belongs. The first is judging by the model instead of the use. A general chatbot is transparency risk, but point that same Granite model at candidate screening and Annex III makes it high risk. The tier follows what the output decides, not how clever the model is. The second is confusing intent with deployment. A team builds an internal tool for summarising tickets, tags it minimal, then a product manager wires its output into an automated refund decision. The intended purpose changed, the tier changed with it, and nobody rewrote the classification.

The third pattern is assuming a vendor carries your obligations. Consuming Granite through watsonx.ai leaves IBM as the GPAI provider, which is real relief on the model documentation. It does nothing for your deployer duties: the human oversight, the logging, the transparency notice on your chatbot. Those are yours regardless of whose model sits underneath. The fix for all three is the same discipline, and it is cheap. Re-run the tier classification whenever the use case, the audience, or the downstream action changes, and treat a change of intended purpose as a trigger, not a footnote. A tier set once at project kickoff and never revisited is the single most common way a compliant system drifts into a non-compliant one without anyone deciding to break the rules.

Map your systems to the risk tiers first

If you do one thing this quarter, inventory every AI feature that reaches an EU user and put a tier next to each. Not a policy, not a committee, just a list with a role and a tier per row. That single sheet tells you which systems have a 2026 deadline and which have until 2027, and it stops the whole team from treating one delayed headline as permission to wait. Most of your features will land in transparency or minimal, and that is a genuinely light lift. The few that touch hiring, credit, or biometrics are the ones worth your architects this year.

Then open watsonx.governance, run the Risk Identification questionnaire against that inventory, and let the EU AI Act template turn your list into tracked controls. Start the factsheet on day one of the next model you onboard, because backfilling documentation for a system already in production is the slowest, least honest way to do this. Part 22 picks up the operational side, LLMOps on watsonx and OpenShift, where these controls stop being documents and start being pipeline gates.

References

• EU AI Act Article 99, Penalties
• EU AI Act implementation timeline
• Council of the EU, Digital Omnibus agreement
• IBM watsonx.governance product overview
• Preparing for the EU AI Act, IBM Think

Related: Guardrails and Responsible AI in the vendor-neutral GenAI Series.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts