Red Hat Summit Connect Utrecht 2025: AI and Sovereignty

On 15 October 2025 I went back to Red Hat Summit: Connect, Red Hat’s one-day event for the Netherlands. Red Hat’s event page listed it under Utrecht, at the NBC Congrescentrum in Nieuwegein, the same venue as the 2024 edition. This is a throwback post built from my photos, the slides on screen and a few short videos I recorded on the day. Speaker names come from the slides or from Red Hat’s official agenda, and I say which each time.

As a former Red Hat engineer, I find this event a useful check on which parts of the portfolio Red Hat puts in front of Dutch customers. In 2025 the answer was clear from the first slide: AI, sovereignty and cost.

The main hall during the keynote, while the screens showed Red Hat’s “trusted partnership” slide with HCS company and Kangaroot.

The event

The printed “Main agenda”, which matches the official agenda page, ran from 8:00 registration to a reception that lasted until 19:00. The plenary keynote was titled “Innovate freely, operate efficiently: build on a unified AI and application platform”. Both the printed agenda and the official page name Ashesh Badani as keynote speaker, with Elizabeth Gabster and Marcel Timmer of Red Hat as hosts.

After the keynote came four rounds of five parallel breakouts, colour-coded by track: AI, App Platform, Infrastructure, Automation and Virtualization. Customer and partner sessions included Alliander, the Belastingdienst (twice: PostgreSQL with EDB, and a platform journey with HCS Company and Kangaroot), ProRail with Conclusion, Rabobank with ilionx, and LEGO City Police. The day closed with De Speld LIVE, which the official page describes as a live show by the Dutch satirical news site.

When the plenary opened, people were still finding seats. From the stage, one of the hosts said there were 1,400 registrations for the day and called it a sign that the open source community in the Netherlands was thriving.

The plenary about to start, with 1,400 registrations announced for the day.

Before the keynote: a robot dog trained on OpenShift AI

Before the keynote I stopped at the ITQ × NVIDIA stand and recorded a short interview with Johan van Amersfoort, Chief Evangelist and AI Lead at ITQ. Their demo was a robot dog that responds to hand gestures, built on the Red Hat stack to show how ITQ thinks AI should run on OpenShift.

He walked me through how the model evolved:

• Detection. They started with YOLO as the base and trained it to recognise hands on a dataset of 14,000 images, then validated it on a separate dataset.
• Gestures. Training the model on each new gesture didn’t scale. Instead they switched to hand landmarks, 21 points on the hand, and wrote a Python function that turns the landmark positions into a gesture and sends it to the dog. A new gesture now means a new function, not a new dataset and a retrained model.
• Platform. Data gathering, labelling, training and validation ran in an OpenShift AI workbench, and the model was then served from OpenShift as an application.

The live demo did what live demos do: the screen showed the landmarks on his hand, and the thumbs-down was recognised while the thumbs-up didn’t register at first. Johan summed the project up as “making dumb stuff smart using AI”. ITQ kept developing the dog afterwards as Project Q9, and in June 2026 Red Hat published a write-up of the project.

My take: the landmark switch is the lesson I’d take away, more than the dog. Moving the gesture logic out of the model and into ordinary code meant fewer retraining cycles, a smaller dataset problem and behaviour you can unit-test. Not every problem needs another round of training.

The sponsor slide at the start of the keynote listed Intel as lead sponsor. Diamond sponsors were HCS company, Kangaroot and Conclusion. Gold: AWS, EDB Postgres AI, Dell Technologies, ilionx and Portworx. Silver: Devoteam, F5, HashiCorp, IBM, ITQ, Kyndryl, SLTN and Veeam. Bronze: Axians, Checkmk and Vijfhart.

The expo floor from the balcony at the end of the keynote: “Bring your curiosity” columns, the ITQ × NVIDIA stand on the left and the Dell × AMD stand on the right.

Keynote: AI priorities and the skills gap in the Netherlands

The keynote opened with Dutch survey numbers, each marked with an asterisk for a footnote I couldn’t read from my seat. Under “The Netherlands AI priorities for the next 18 months” were three nearly equal scores: AI sovereignty (86%), ensuring transparency and openness (85%) and cost optimization (84%).

The next slide was “The top skills gap in The Netherlands, according to AI and IT leaders”: cloud computing skills (81%), social skills (80%), full stack development skills (79%), operational skills (78%), security skills (78%) and AI skills (75%).

Left: sovereignty, openness and cost scored almost the same as AI priorities. Right: AI skills (75%) came last in the skills-gap list, behind cloud computing (81%).

That second slide is worth a closer look. AI skills were the smallest gap on the list. The larger gaps were the ones underneath AI: cloud, operations, security and full stack development.

The argument then moved to sovereignty: “Open source is foundational to digital sovereignty”. Open source software “provides transparency and trust” at three levels: Technology (Linux, Java, Ansible, Kubernetes, Podman, vLLM and other project logos), Community (the Cloud Native Computing Foundation, the Linux Foundation and Hugging Face) and Control (private cloud, public cloud and edge).

Sovereignty as Red Hat framed it: open technology, open communities and control over where workloads run.

Keynote: modernisation on Red Hat platforms

The next part opened with “Business is driven by major technology waves”, followed by an ROI slide, “Building success on Red Hat platforms”. It quoted a 3-year ROI of 540% for Red Hat Enterprise Linux, 668% for Ansible Automation Platform and 468% for OpenShift, each with a footnote to its source. An “Efficiency” slide showed managed OpenShift in the cloud on AWS, Microsoft Azure, Google, IBM and Oracle, and OpenShift Lightspeed, the AI assistant.

Modernisation came in three parts: virtualisation, IT operations “with automation and AI”, and developer productivity.

• Virtualisation. “Modernizing your virtualization infrastructure” showed a Red Hat Services path in four steps: a virtualisation migration assessment (strategy), a proof of value (foundation), a migration factory (expansion), and optional app modernisation and automation (evolution). The “OpenShift Virtualization adoption” slide was a wall of customer logos, among them Ford, NASA, Ericsson, Paychex, NetApp, SiriusXM, Orange, Sopra Steria and Emirates NBD.
• IT operations. “Modernizing IT operations” mapped three needs to Ansible products: standardised automation operations to Ansible Automation Platform, event-driven automation and AIOps to Event-Driven Ansible + Ansible Lightspeed, and “policy enforcement of all automation” to Ansible Policy as Code.
• Developer productivity. “Modernize developer productivity” introduced the Red Hat Advanced Developer Suite: Trusted Software Supply Chain for better security, Red Hat Developer Hub for collaboration, and OpenShift GitOps and OpenShift Pipelines for faster deployments. The slide’s numbers: 86% of organisations develop cloud-native applications, 76% say learning their architecture means a high cognitive load, and malicious packages grew 156% year on year.

Left: OpenShift Virtualization customers. Right: the Ansible portfolio as three answers to three operations problems.

Keynote: open hybrid cloud plus AI

The AI section began with “AI is a strategic enabler across industries”. Its subtitle read: “Predictive AI runs businesses today; generative AI brings innovation to the enterprise”. Use cases were grouped into revenue generation (chatbots, guided selling, developer assistants), cost optimisation (automated AI support, knowledge-base search and summarisation, AI-optimised logistics) and risk management (fraud detection, contract risk assessment, AI-assisted security operations).

Then came the stack slide I photographed twice: “Open Hybrid Cloud + AI enables Cost Reduction, Choice, and Flexibility”. From top to bottom: applications, AI LLM models, MCP/Agents and Llama Stack; then Kubernetes next to llm-d; Linux and vLLM on CPU and GPU; and Automation next to AIOps. The labels on the left read application and model choice, scalable management, cost reduction and hardware choice. Along the bottom were six footprints: physical, virtual, private, sovereign, public and edge.

The AI platform on one slide: vLLM and llm-d for inference, MCP and Llama Stack for agents, and “sovereign” as a footprint of its own.

The section closed with “Open Hybrid Cloud + AI enables successful Technology Era transition”: Red Hat AI on top of the Red Hat open hybrid cloud, to “accelerate the development and delivery of AI solutions across hybrid cloud environments”.

Lead sponsor Intel then had its own slot. The title slide read “Advancing AI, Virtualization and Platform Security”, by Joost Weppner, EMEA Partner Programs Director (name and title from the slide). His “The Intel Advantage” slide presented at-scale manufacturing as silicon and platforms, software, and packaging and process, under the line “The Leading Provider of Silicon Globally”. That is Intel’s own claim.

Alliander and the agentic AI session with Intel

The first breakout round started at 11:30. I caught the opening of the Alliander customer session. The slide introduced Marc Budie (Product Owner Transport Development, Alliander) and Stefan Richter (Grid Modernization Strategist, Red Hat). The official agenda gives the title as “Red Hat in the Electrification Market: Alliander’s Journey to Software-Defined Operational Technology”.

The Alliander session: a grid operator’s journey to software-defined operational technology, introduced on stage.

A few minutes in, I switched rooms to “Agentic AI in Action: Red Hat & Intel Shaping the Future of Enterprise AI”. The official agenda lists Jurgen Eijmberts (Intel) and Kyra Goud (Red Hat) as speakers, and its abstract mentions Intel Gaudi 3 and the Model Context Protocol. The slides I photographed covered three building blocks:

• Confidential AI. “Confidential AI Helps Protect Data & Models In-Use”, subtitled “Utilizing Confidential Computing for Containers with Intel TDX”. The diagram combined hardware-based protection with Intel Trust Domain Extensions, OpenShift / OpenShift AI sandboxed containers and the Confidential Containers project. The bottom line read: “Confidential Computing is about protecting data in-use. You do not have to trust the system admins of the providers any longer.”
• Inference. “Red Hat AI the inference engine for the hybrid cloud”, with “vLLM supports the key models on the key hardware accelerators”. The models were Llama, Qwen, DeepSeek, Gemma, Mistral, Molmo, Phi, Nemotron and Granite. The accelerators were NVIDIA GPUs, AMD Instinct, Google TPU, AWS Neuron, Intel Gaudi and IBM Spyre.
• Models. “Red Hat AI repository on Hugging Face: a collection of third-party validated and optimized large language models”. Validated meant tested in realistic scenarios and assessed for performance across hardware, using GuideLLM and LM Eval Harness. Optimized meant compressed with LLM Compressor to run faster on fewer resources while keeping accuracy.

Left: confidential containers with Intel TDX. Right: vLLM as the layer between many models and many accelerators.

Validated and optimised third-party models, published by Red Hat AI on Hugging Face.

Then came the demo, which I recorded. The scenario was an employee asking whether they’re entitled to a benefit under their country’s regulations and their company’s rules. In this case it was leave to care for a parent who’d had an accident. The architecture had a UI in front of a Llama Stack distribution that talks to the models, a RAG tool over the regulation documents, and an MCP server in front of an eligibility engine with a rule table that applies the regulations to a specific person.

On the platform side, the presenter showed OpenShift AI on Intel Gaudi 3 PCIe accelerators, with vLLM serving-runtime profiles for Gaudi. A model was picked from the catalogue of third-party validated models (a Mistral model card), and Granite was already deployed. A CPU serving runtime was available too. The speakers also mentioned an example that spreads a workload over both Xeon CPUs and a Gaudi accelerator, with the Gaudi load rising only when the application needs it.

The chat playground then answered the same question three times:

1. No tools. The model answered from its system prompt alone and said there would be no payment, which was wrong.
2. With RAG. It called the retrieval tool and found the rulebook that applied, but still couldn’t say whether this employee qualified.
3. With the eligibility engine over MCP. It knew the user’s profile and their relationship to the person needing care, and confirmed the benefit. Switching to a different user changed the relationship, and with it the requirements in the answer.

My take: the useful part of this demo wasn’t the model. The personalised answer came from a deterministic rule engine behind MCP, and the LLM’s job was to call it and phrase the result. That’s the pattern I recommend for anything regulated: keep the decision in code you can audit, and let the model handle the language.

A benchmark slide in the same session claimed “up to 36% higher throughput than NVIDIA H200” and “up to 200% higher throughput than NVIDIA H100” for large AI workloads. These are vendor numbers from the session, and I could not read the footnotes, so treat them as such.

Platform engineering and the software supply chain

In the third round I went to “Platform engineering your way to software supply chain security - Red Hat Advanced Developer Suite”. The official agenda credits it to Markus Nagel of Red Hat. The overview slide described RHADS as combining “platform engineering tools with enhanced security capabilities”, with a modular design that integrates with existing platforms. It works with Red Hat Advanced Cluster Security, complements OpenShift Dev Spaces, and is built on Backstage and Sigstore. The diagram had platform engineers defining and developers consuming. Developer Hub (with “+250 community plugins”) sat next to Trusted Profile Analyzer and Trusted Artifact Signer, all on OpenShift and OpenShift AI.

Red Hat Developer Hub got its own slide: “An Internal Developer Portal (IDP) based on the CNCF Backstage project”. It promised faster onboarding, automated software templates, self-service, and a central source of truth.

Left: what the Advanced Developer Suite bundles. Right: the security-augmented development process, from signed commit to GitOps deployment.

The process slide ran from Code (Red Hat Dependency Analytics, commits signed with gitsign) through Build (git pull, Maven package, container build, push to registry) to Deploy (a GitOps repository with Kubernetes deployment definitions, deployed to OpenShift) and Monitor. Dependencies and base images came from trusted content. A live demo then opened a project in the IDE and ran the Red Hat Dependency Analytics report. Its “Red Hat Overview of security Issues” panel counted 23 vulnerable dependencies (8 high, 15 medium), followed by a “Red Hat Remediations” section.

On camera with ITQ

After lunch, ITQ invited me as a guest on its Cloud Native Chronicles series. We talked mostly about automation, and three points from that conversation are worth writing down:

• Terraform and Ansible aren’t rivals. Most setups I see use both: Terraform to provision resources, then Ansible for the final touch: users, application deployments, connecting to the log management system and day-2 operations. I covered the split in Terraform vs Ansible: when to use which.
• GitOps with Ansible. Ansible content belongs in Git like everything else: playbooks and inventories in a repository, applied by a pipeline such as Jenkins, GitLab CI or GitHub Actions. What Ansible lacks compared to Argo CD is an agent that keeps watching for configuration drift, so it doesn’t fully meet the GitOps principles on its own. That matters because many applications still aren’t microservices running in a cluster.
• Supply chain. One feature of Ansible Automation Platform I like is content signing, so you can verify that playbooks haven’t been tampered with on their way to production.

2025 compared with 2024

Same venue, same lead sponsor, and some clear changes:

• Tracks. In 2024 there were four tracks (IT Automation; Application Platform & Cloud Services; The Power of AI; Cloud & Infrastructure). In 2025 there were five, with Virtualization as a track of its own. Its sessions covered OpenShift Virtualization at scale with Ansible Automation Platform, and real-world lessons from Portworx.
• AI story. In 2024 the keynote was about Granite, InstructLab and RHEL AI: getting your own knowledge into a smaller open model. In 2025 the keynote talked about inference and agents instead: vLLM, llm-d, MCP, Llama Stack and validated models on Hugging Face. The new framing was sovereignty.
• Supply chain. Some things didn’t change. A slide titled “A security-augmented development process” appeared in the 2024 trusted application pipeline session too. In 2025 it was packaged as the Advanced Developer Suite.

My take

The Dutch survey numbers are the part I would show a board. Sovereignty, openness and cost all scored above 84%, and AI skills were the smallest skills gap. My view is that the bottleneck is rarely the model. It’s the cloud, operations and security skills underneath it. That’s why the keynote’s stack slide makes sense to me. vLLM and llm-d on Kubernetes, behind an automation layer, is a platform an operations team can run and audit anywhere: private, public, edge or a sovereign region. I wrote about that layer in Model Serving on OpenShift AI with vLLM and llm-d: Kubernetes-native distributed inference. The single-server starting point is in my RHEL AI tutorial.

Confidential containers deserve more attention in sovereignty discussions than they get. “You do not have to trust the system admins of the providers” is a stronger argument than “the data centre is in the EU”, and it is testable. See Confidential Containers on Kubernetes for how it works.

On the operations side, the Ansible slide matches how I would split the work: a platform for standard runs, Event-Driven Ansible for reacting to events, and policy as code on top. VM migrations belong on the same platform as the containers, as I described in Operationalizing OpenShift Virtualization. For a newer Red Hat Netherlands event, see my notes from Red Hat Tech Day Netherlands 2026. My notes from the main Red Hat events are collected on the Red Hat Summit page.

Related

• Red Hat Summit Connect Utrecht 2024: AI, Ansible, OpenShift
• Red Hat Tech Day Netherlands 2026: Harness Engineering
• Model Serving on OpenShift AI with vLLM
• Confidential Containers on Kubernetes