A brief history of LiipGPT and ZüriCityGPT

2023, Chregu released the first version of LiipGPT. 2024, we were able to use only open-source models on ZüriCityGPT. 2025, we switched the open-source version to the newly released Apertus model. In this blog post, we talk about the insights gained since then.

Setting up the experiment

LiipGPT, our generative AI framework, has a pluggable model layer. That means we can swap the underlying language model without changing anything else — same Retrieval-Augmented Generation (RAG) pipeline, same knowledge base of official content from stadt-zuerich.ch. This gave us a straightforward way to compare models in a real deployment.

The production system at zuericitygpt.ch runs GPT-4o-mini on Azure Europe. Alongside it, we run an open-source variant at oss.zuericitygpt.ch where in the past we compared Llama and Mixtral models. We switched the open-source variant to Apertus-70B when it was released in September 2025, then moved to Infomaniak-hosted Apertus in April 2026. (To be clear: ZüriCityGPT itself and the LiipGPT platform are not open source — but the underlying language model on the OSS variant is.)

We run Apertus as the 70-billion-parameter model. It was trained from scratch on the Alps supercomputer using Swiss hydroelectricity, with 15 trillion tokens of training data spanning over 1,800 languages. It is fully open-source under an Apache 2.0 licence.

Over the last eight months, we collected over 39,000 conversations on the production side and 3,400 on the open-source side. Quality is measured using three metrics: how often an answer is acceptable (Match Rate), how often it is actually good (Match Rate +1), and how faithfully it reflects the source documents (Faithfulness). These are metrics our LiipGPT team has established as practical product metrics, not scientific benchmarks — the data is calculated real-time and asynchronously by the LiipGPT platform while users ask different questions over time, evolving website content, and model endpoint changes. Parts of the analysis were prepared with the help of Claude. Our aim is not to provide a scientific study but more a practical report. I share these results with the Apertus community because real-world deployment data of this open-source model is rare — and we think it's useful.

What we observed

Both models get the job done. On the basic question — does the user get an acceptable answer? — both models perform similarly. GPT-4o-mini scores 81%, Apertus 82% on historically matched questions. In a controlled test with 20 identical questions asked at the same moment, both hit 100%. Both models generally work as expected.

The gap shows up in answer quality. When we raise the bar to "is this answer actually good?", GPT-4o-mini scores 72% and Apertus 55%. That is a noticeable difference, and it matters for users who expect precise, well-structured responses.

Faithfulness is more nuanced than we expected. GPT-4o-mini averages 0.79, Apertus 0.50 on our faithfulness metric. But these numbers need context. We noticed something we started calling the "faithfulness paradox": when a model says "I cannot answer this," you might expect high faithfulness — no hallucination, after all. In practice, these evasive answers score low because the model is failing to use information that is available. A model that engages with its sources and cites them scores higher, even though it is making more verifiable claims. Both behaviours have tradeoffs, and both showed up across the two systems.

Sometimes Apertus gave the better answer. The most striking example was the waste dump question: "What are the rules for using the Zurich waste dump?" GPT-4o-mini responded cautiously, saying it could not provide specific rules. Apertus gave a detailed, structured answer with recycling centre details, phone numbers, and cited sources — scoring 6/6 on quality where GPT-4o-mini scored 3/6. When the knowledge base contains a clear, structured answer, Apertus can be surprisingly good at extracting and presenting it.

That said, this willingness to commit cuts both ways. In cases where the source material is ambiguous, Apertus can feel more helpful while being less strictly grounded — and for public-sector chatbots, traceability matters as much as helpfulness.

GPT-4o-mini is more concise and better at synthesis. Apertus tends to produce longer, more verbose answers. In a public-service chatbot, that is a real UX issue — users want a direct answer with clear next steps, not three paragraphs of context.

GPT-4o-mini also handles factual freshness better: it returned Zurich's current population (452,421), while Apertus fell back to a 2013 figure. When information has changed or the answer requires connecting multiple sources, GPT-4o-mini felt more reliable.

Language switching is a weak spot. When we asked "Est-ce que tu parles français?", GPT-4o-mini responded fluently in French. Apertus declined, saying it could not answer questions about its own linguistic capabilities. In more recent tests we saw that Apertus followed the language instructions in better ways, so we are looking forward to see this further improve.

The Apertus-70B IFEval score of 44% (vs 58% for comparable models) confirms that instruction following is an area where the model has room to grow.

The trend is positive. In October 2025, Apertus achieved a Match Rate +1 of 59%. By June 2026, it had climbed to 63% — the best month on record. That is not a dramatic leap, but the direction is consistent and it came without a major model update. Meanwhile, GPT-4o-mini has been stable at 63–83% throughout. The gap is narrowing.

What we are looking forward to

The Apertus team is preparing version 1.5, with improvements expected in multimodal support, agentic capabilities, tool calling, enhanced reasoning, and better training for regional Swiss languages. We plan to update ZüriCityGPT's open-source instance as soon as it becomes available and continue our quality monitoring.

What encourages us most is that the collaboration is flowing in both directions. After our aiLights talk, the Apertus team shared our findings with their staff. This close feedback loop between research and practice is exactly what makes the Swiss AI ecosystem worth investing in.

My practical advice, for anyone considering sovereign AI: start with the use case, then choose the model. If your priority is maximum answer quality today, more popular models are usually the stronger choice. If your priority is data sovereignty, transparency, and independence — and your knowledge base is well-curated — Apertus already delivers. The question is not "sovereign AI or quality" but "how much quality gap are you willing to accept for full sovereignty?" And that gap is closing.

Check the Slides and Recording for further details.

Acknowledgements

I would like to thank the ETH Zurich, EPFL, and the wider Swiss AI Initiative community for making Apertus available as a public good. As Martin Jaggi from EPFL put it: "We aim to provide a blueprint for how a trustworthy, sovereign, and inclusive AI model can be developed." (source) Eight months in, we can see that blueprint taking shape and are looking forward to test the 1.5 model in practice as well.

• Thank you Christian Stocker and the LiipGPT team for your dedication to build a practical, experiment-driven and scalable solution for AI chat and search.

• Thank you Sabine Wildemann and the aiLights team for hosting our talk.

• Thank you Oleg Lavrovsky and the Apertus community for your feedback and support.

• Thank you Public AI and our partner Infomaniak for providing the infrastructure.

Build with Apertus: join Hack Apertus

Want to get hands-on with sovereign Swiss AI? Hack Apertus is a two-stage open-source hackathon series where teams build on Apertus to develop blueprints for sovereign infrastructure across the public and private sector. Liip is a partner — we are excited to see what the community builds.

Sign up at hackapertus.ch.

Das Portal fr.ch vereint eine grosse Menge an Verwaltungsinformationen: Verfahren, Gesetzgebung, Formulare, kantonale Dienstleistungen sowie Informationen der Gemeinden. Auf einer so umfangreichen Website die richtige Antwort zu finden, ist nicht immer einfach.

Du stellst deine Frage ganz normal, so, wie du sie auch einer Person stellen würdest. Obwohl fr.ch in Französisch und Deutsch verfügbar ist, wie es sich für einen zweisprachigen Kanton gehört, können Fragen in jeder beliebigen Sprache gestellt werden. So erhalten auch Bürger*innen, die keine der beiden Amtssprachen sprechen, Zugang zu den benötigten Informationen.

Der KI-Chatbot identifiziert relevante Inhalte auf fr.ch sowie in der Freiburger Gesetzessammlung und erstellt daraus eine Antwort. Dabei verweist er auf die offiziellen Quellen, die für die Antwort herangezogen wurden.

Diese Transparenz ist zentral. Die KI ersetzt keine offiziellen Inhalte, sie erleichtert den Zugang dazu.

KI im Zeichen digitaler Souveränität

Die Datensouveränität stand im Mittelpunkt des Projekts. Für die Staatskanzlei war es entscheidend, die vollständige Kontrolle über die Infrastruktur und die Datenverarbeitung zu behalten.

Der Chatbot basiert auf LiipGPT, unserer Plattform für generative KI. Unsere Retrieval-Augmented-Generation-Technologie (RAG) wählt für jede Anfrage die relevanten offiziellen Inhalte aus. Die Lösung wird bei Exoscale in der Schweiz gehostet.

Als Large Language Model (LLM) setzen wir auf Mistral AI, einen der führenden europäischen Anbieter. Dieses Modell wird in der Schweiz von Infomaniak betrieben, einem Vorreiter für nachhaltiges und umweltbewusstes Webhosting. Die Server des LLM werden ausschliesslich mit erneuerbarer Energie betrieben und setzen auf natürliche Kühlung, Wärmerückgewinnung, optimierte und wiederverwendete Hardware sowie lokale CO₂-Kompensation.

Diese Architektur reduziert die Abhängigkeit von grossen US-amerikanischen Plattformen und setzt auf einen schweizerischen und europäischen Ansatz für generative KI. Anfragen werden anonymisiert, und es werden keine personenbezogenen Daten an Dritte weitergegeben. Die gesamte Lösung bleibt unter schweizerischer Rechtshoheit und erfüllt die geltenden Datenschutzbestimmungen.

Eine Zusammenarbeit mit starken Wurzeln in der Westschweiz

Die Staatskanzlei Freiburg hat das Projekt mit einer klaren Vorstellung der administrativen und politischen Anforderungen geleitet. Unser Team, unter anderem mit Mitarbeitenden in Freiburg, entwickelte die Lösung in enger Zusammenarbeit mit der Staatskanzlei. So konnten wir optimal auf die tatsächlichen Bedürfnisse eingehen.

Diese Nähe ermöglichte kurze Abstimmungswege und einen starken Fokus auf die Nutzer*innen-Erfahrung. Neben der technologischen Umsetzung ging es darum, ein Werkzeug zu schaffen, das für die Freiburger Bevölkerung nützlich, verlässlich und verständlich ist.

Ein erster Schritt hin zu einer zugänglicheren Verwaltung

Seit dem ersten Rollout im März haben wir verschiedene Elemente weiterentwickelt, um die Qualität der Antworten kontinuierlich zu verbessern. Dabei profitiert unsere Kundin insbesondere von unseren automatisierten Evaluationslösungen, mit denen die Qualität der generierten Antworten fortlaufend überprüft werden kann.

Diese erste Version deckt die öffentlichen Informationen auf fr.ch sowie die Freiburger Gesetzessammlung ab. Der Inhalt beschränkt sich jedoch nicht allein auf das kantonale Portal: Er wird schrittweise um Informationen erweitert, die von anderen kantonalen Institutionen und bestimmten Gemeinden veröffentlicht werden. Mit jeder neuen Quelle nimmt auch die Bedeutung einer konsequenten Qualitätssicherung zu. Der Kanton Freiburg unterhält übrigens eine eigene Seite zum Chatbot, auf der unter anderem die verwendeten Datenquellen aufgeführt sind.

Eine Überzeugung begleitet uns dabei: KI im öffentlichen Sektor kann souverän, transparent und nützlich sein. Voraussetzung dafür ist, die Kontrolle über die Infrastruktur zu behalten und die verwendeten Quellen jederzeit offenzulegen.

Möchtest du dich über KI in deiner Institution austauschen?

Die klare Trennung zwischen Services und Verwaltungsorganisation macht den Zweck der Plattform sofort verständlich und zeigt ihren Mehrwert für Einwohner*innen und Unternehmen. Dadurch wird die Intention der Website unmittelbar erkennbar, und alle Inhalte sind logisch und konsistent aufgebaut. Das sehen nicht nur wir so: Auch die BOSW-Jury hat dies gewürdigt und die Website in diesem Jahr mit Bronze in der Kategorie User Experience ausgezeichnet (kleiner humblebrag: Wir haben gleich zwei der drei Podestplätze geholt, Silber ging ebenfalls an uns für den Relaunch der Website des Museum für Gestaltung Zürich).

Informationsarchitektur - konsequent aus Nutzersicht gedacht

Die Informationsarchitektur ist sorgfältig konzipiert und auf die Bedürfnisse der Zielgruppen abgestimmt. Alle Services sind zentral gebündelt, klar kategorisiert und folgen einer einheitlichen Struktur: Was brauche ich? Wie läuft der Prozess ab? Welche Kanäle stehen zur Verfügung?

Diese Standardisierung hilft, relevante Informationen schnell zu erfassen und sicher durch komplexe Abläufe zu navigieren. Gleichzeitig werden alle Serviceinformationen transparent dargestellt, sodass auch Gelegenheitsnutzer*innen sofort verstehen, welche Schritte erforderlich sind.

Funktionalität, Interaktivität und Usability für mehr Effizienz

Die Funktionen der Website sind konsequent auf die Bedürfnisse der Nutzer*innen ausgerichtet. Jede Service-Seite bietet klare, verständliche Anleitungen und intuitive Elemente, die einfach zu bedienen sind. Nutzer*innen werden bei jedem Schritt unterstützt, egal ob bei digitalen Services oder bei analogen Angeboten wie Formularen, Telefonaten oder Schalterbesuchen.

Das reduziert Unsicherheiten, vermeidet unnötige Rückfragen und macht die Nutzung kantonaler Leistungen effizienter.

Eine inklusive Website für alle Nutzer*innen

so.ch erfüllt die Anforderungen an digitale Barrierefreiheit gemäss WAI-Richtlinien und ermöglicht so allen Nutzer*innen einen gleichberechtigten Zugang. Die Inhalte sind verständlich formuliert, die Navigation ist konsistent, die Interaktionen sind intuitiv und die Plattform unterstützt sowohl digitale als auch analoge Zugänge.

So wird sichergestellt, dass die Website unabhängig von technischer Erfahrung, Alter oder Beeinträchtigung effizient und selbstständig genutzt werden kann.

Durch die konsequente Ausrichtung auf die Bedürfnisse der Nutzer*innen bietet so.ch eine intuitive, transparente und inklusive Plattform, die komplexe Verwaltungsprozesse verständlich macht. Klare Ziele, eine durchdachte Informationsarchitektur, zugängliche Funktionen und barrierefreies Design schaffen gemeinsam eine nutzerzentrierte Erfahrung, die die Interaktion mit kantonalen Services vereinfacht und effizient gestaltet.

Möchtest du die Website deiner Verwaltung verbessern? Ich freue mich, von deinen Bedürfnissen und Herausforderungen zu hören.

Ende 2022 habe ich zum ersten Mal ChatGPT in einem Video auf TikTok gesehen und habe es direkt ausprobiert. Ich konnte mir Inhalte schneller erklären lassen als meine Lehrpersonen, Aufgaben besser lösen, als wenn ich es selbst machen würde, und sogar Ideen entwickeln, auf die ich nie gekommen wäre. Das faszinierte mich sehr.

Aber wie mächtig und auch wichtig KI wirklich ist, wurde mir erst anfangs meiner Lehre klar. Heute nutze ich sie täglich. Nicht, damit sie meine Arbeit macht, sondern damit ich mir selbst Neues beibringen kann, gezielter recherchieren kann und bei bestimmten Aufgaben effizienter vorankomme.

Meine Lehre ist vielseitig. Genau das macht sie spannend

Ich mache eine Lehre als Entwickler Digitales Business EFZ. Ich bin momentan im zweiten Lehrjahr. Nach dem ersten Jahr im Bbc Basislehrjahr arbeite ich seit Sommer 2025 bei Liip.

An dieser Lehre finde ich besonders spannend, dass ich viele verschiedene Aufgaben habe. Ich arbeite in verschiedenen Circles, selbstorganisierte Teams nach Holokratie, mit. So lerne ich viele unterschiedliche Perspektiven, Aufgaben und Personen kennen.

Ich bin im Finance Circle gestartet, da ging es stärker um Datenmanagement. Seither hatte ich die Möglichkeit, in verschiedene weitere Teams reinzuschauen und jeweils andere Aufgaben, Perspektiven und Arbeitsweisen kennenzulernen. Heute arbeite ich im Content- und Design Circle mit Fokus auf Prozessoptimierung, Automatisierung und KI. Ich lerne auch noch einige andere Circles, Aufgaben und Rollen im Laufe meiner Lehre kennen.

Diese Vielfalt passt gut zu mir. Ich arbeite gerne strukturiert, kommuniziere aktiv und finde es spannend, Abläufe zu analysieren und zu verbessern. Bei Liip habe ich die privilegierte Chance bereits früh in der Lehre Verantwortung zu übernehmen. Ich arbeite an wirkungsvollen internen und externen Projekten mit, treffe Entscheidungen und bringe eigene Ideen ein. Das unterscheidet Liip für mich stark von vielen anderen Ausbildungsorten.

Der Umgang mit Kund*innen gehört dazu

Ein Teil meiner Lehre, der von aussen vielleicht weniger sichtbar ist, ist der Umgang mit Kundinnen. Ich lerne, professionell zu kommunizieren, die eigene Firma gut zu vertreten und wichtige Faktoren für eine gute Zusammenarbeit kennen. Das bedeutet zum Beispiel, Informationen im Team klar zu vermitteln, Anforderungen abzuholen und in Projekten strukturiert zu kommunizieren. Weil ich als Lernender früh bei echten Projekten mitwirke, entwickle ich ein gutes Gespür dafür, was Kundinnen wirklich wichtig ist.

Wie ich KI konkret nutze

KI wird besonders hilfreich, wenn ich viel Kontext gebe. Dann wird aus einem allgemeinen Tool ein wertvoller Sparringspartner. KI unterstützt mich vor allem, wenn ich ein klares Ziel habe und schnell einen guten ersten Entwurf brauche. Ich nutze sie zum Beispiel für Brainstormings, um neue Begriffe zu verstehen, für Recherchen oder um Texte zu strukturieren.

• Fun Fact am Rande: Auch dieser Blogpost wurde teilweise mit KI strukturiert. Ich habe meine Gedanken gesammelt, den Kontext erklärt und mir dann helfen lassen, eine sinnvolle Struktur zu erstellen. So nutze ich KI im Alltag.

Ein gutes Beispiel ist das Manual für das LiipGPT Backend, das ich geschrieben habe. Am Anfang hatte ich praktisch keine Erfahrung mit dem Schreiben von Manuals. Deshalb habe ich mir zuerst mithilfe von KI die Basics beigebracht. Danach habe ich der KI so viel Kontext wie möglich mitgegeben und Schritt für Schritt mit ihr einen Entwurf entwickelt. Am Ende entstand ein Handbuch, das intern oft genutzt und für Kund*innen individuell ausgebaut wird. Für mich war das ein Moment, in dem ich merkte, wie viel Mehrwert KI bringen kann, weil ich nicht nur schneller und ohne Erfahrung arbeiten konnte, sondern auch ein Ergebnis entstanden ist, das anderen im Alltag wirklich hilft.

Ich nutze diese Tools nicht unüberlegt. Ich teste sie, vergleiche sie und überlege genau, für welchen Anwendungsfall sie wirklich sinnvoll sind.

KI ist mein bester Lernbuddy

KI hat grosses Potenzial beim Lernen. Sie vereinfacht Inhalte, liefert Beispiele und passt sich an mein Niveau an. Das schafft kein Lehrbuch. Der Einstieg ins Thema gelingt so schneller. Als Lernender stelle ich der KI Fragen und Rückfragen, die ich mir im Unterricht nicht zu stellen trauen würde.

Gleichzeitig gilt jedoch: KI darf das eigene Denken nie ersetzen. Wer nicht versteht, wie KI funktioniert und wie sie genutzt werden kann, lernt am Ende wenig.

Für mich gehören Offenheit und kritisches Hinterfragen zum Umgang mit neuen Tools dazu. KI kann Lernende stärken, aber nur, wenn sie bewusst als Werkzeug genutzt wird. Darum ist es wichtig, dass sich Lernende schon in der Ausbildung mit KI beschäftigen. Nicht erst später, wenn alle anderen längst routinierte Nutzer*innen sind.

Wie nutzt du KI?

Vielleicht lohnt es sich, nach diesem Text kurz innezuhalten und über den eigenen Umgang mit KI nachzudenken. Wie nutzt du KI heute wirklich in deinem Alltag? Welchen konkreten Mehrwert bringt sie dir dabei? Ist sie für dich nur ein Werkzeug, das du ab und zu ausprobierst? Oder setzt du sie bewusst ein, um besser, schneller oder strukturierter zu arbeiten?

Bei Liip erlebe ich direkt, wie eine Organisation KI nicht nur nutzt, sondern aktiv mitgestaltet:

• Regelmässige Wissensaustausche und Liip Talks zu KI, von neuen Modellen bis zu ethischen Fragen.
• KI Trainings für alle Mitarbeitenden. Intern bieten wir Workshops und spezielle Module an, damit alle sicher im Umgang mit KI bleiben.
• Entwicklung und Weiterentwicklung eigener KI Tools wie LiipGPT, das bereits bei Kund*innen aus dem Gesundheits-, Rechts- und öffentlichen Bereich im Einsatz ist.
• AI Sustainability Guidelines, ein interner Rahmen, der sicherstellt, dass KI Projekte ethisch und nachhaltig umgesetzt werden.

Das zeigt mir, wie eine Organisation aussehen kann, die KI nicht blind einsetzt, sondern Verantwortung dafür übernimmt.

Wie nutzen Mitarbeitende in deinem Unternehmen KI? Gibt es klare Regeln oder Angebote, um KI sinnvoll einzusetzen? Wo könnte KI dich in deiner Rolle konkret unterstützen, wenn du sie gezielter anwendest?

KI ist kein festes Konzept, das für alle gleich funktioniert. Aber wer sie früh nutzt, merkt schnell: Die Frage ist nicht, ob man noch eine Lehre braucht, sondern wie viel mehr man aus ihr herausholt, wenn man KI hat.

Museum für Gestaltung: ein Meisterwerk in den Bereichen Public Value und User Experience

Die neue Website des Museums für Gestaltung Zürich dient als zentrale Drehscheibe für die digitale Kommunikation des Museums und ermöglicht Besucher*innen, mit dem Museum in Verbindung zu treten. In Co-Creation haben wir eine Lösung entwickelt, die es dem Design ermöglicht, für sich selbst zu sprechen und damit einen grösseren Nutzen für die Gesellschaft zu erzielen. Die BOSW-Jury hat dies anerkannt und die neue Website mit Silber in den Kategorien “User Experience” und “Public Value” ausgezeichnet.

Mehr zum ausgezeichneten Projekt

Wie Clelia Kanai, Head of Marketing & Communication, betont:
«Gestaltung bedeutet für uns Klarheit und Verantwortung, auch im Digitalen. Mit Liip hatten wir eine Partnerin, die diesen Anspruch geteilt und mitgetragen hat, von der ersten Konzeptidee bis zum letzten Accessibility-Check. Dass daraus ein Projekt entstanden ist, das die BOSW-Jury mit Silber in den Kategorien User Experience und Public Value auszeichnet, ist für uns Bestätigung und schöne Anerkennung zugleich.»

so.ch: Transparenz, Accessibility und Benutzerfreundlichkeit stärken das Vertrauen der Öffentlichkeit

Wir haben für den Kanton Solothurn eine neue Website entwickelt: so.ch. Sie schafft echten Public Value, indem sie kantonale Dienstleistungen transparent, barrierefrei und verständlich macht und so das Vertrauen der Öffentlichkeit, der Behörden und der Wirtschaft in öffentliche Dienstleistungen stärkt.

Wie uns bs.ch bereits letztes Jahr gezeigt hat, ist eine nutzerinnenzentrierte Website entscheidend, um den Alltag der Bürger/innen zu verbessern, die immer häufiger ihre Informationen und Dokumente online finden müssen. Die Jury hat die Qualität der User Experience anerkannt und uns in dieser wichtigen Kategorie mit Bronze ausgezeichnet.

Mehr zum ausgezeichneten Projekt

Auch wenn wir nicht ganz so viele Preise gewonnen haben, wie wir uns gewünscht hätten (und natürlich auch verdient hätten :), war es spannend, den Puls der Branche zu spüren. Wir gratulieren «Swissgrid 24/7» herzlich zum Titel «Master of Swiss Web 26». Bis nächstes Jahr!

Im Kontext jüngster politischer Entwicklungen wurde hier und dort in Nachhaltigkeitsfragen (immerhin) ein «Do-Talk-Gap» attestiert. Die Zurich Climate Week setzt hier an: Sich für den Klimanotstand einsetzen und darüber sprechen.

Und genau das braucht es jetzt. Denn nachhaltige Transformation passiert nicht im Stillen. Sie entsteht dort, wo unterschiedliche Perspektiven und Efforts zusammenkommen: Wirtschaft, Politik, Wissenschaft und Zivilgesellschaft. Wo Wissen geteilt wird. Wo Lösungen gemeinsam entwickelt und skaliert werden.

Warum wir uns engagieren

Bei Liip haben wir uns aus mehreren Gründen dafür entschieden, uns am Programm der Zurich Climate Week zu beteiligen:

• Um das Vorhaben zu stützen, indem wir das Programm mittragen.
• Um unser Commitment für Nachhaltigkeit über die Climate Week hinaus zu stärken.
• Und nicht zuletzt: um unsere Erfahrungen zu teilen, von anderen zu lernen und unser Netzwerk mit Gleichgesinnten zu vergrössern.

Unser Beitrag zur Climate Week steht – genauso wie die beiden Themenbereiche, die wir mit unseren Events adressieren – im Zeichen: Verantwortung übernehmen.

Unser Beitrag

Liip ist mit zwei Formaten im Programm vertreten – beide mit einem klaren Fokus auf Austausch, Praxisnähe und konkrete Umsetzbarkeit.

Hacking for Sustainable AI

Weitere Infos & Anmeldung

Künstliche Intelligenz ist längst Teil unseres Alltags. Sie scheint für viele Probleme Lösungen zu bieten – und oft ist sie der erste Anlaufpunkt, wenn wir nicht weiterwissen. Gleichzeitig stellen ökologische und gesellschaftliche Auswirkungen weiterhin ungelöste Herausforderungen dar.

Wann schafft der Einsatz von KI tatsächlich einen Mehrwert? Und wie können wir sie so nutzen, dass sie zu einer nachhaltigeren Zukunft beiträgt?

Gemeinsam mit opendata.ch bringen wir diese Fragen in einem Mini-Hackathon auf den Tisch. Entwickler:innen, Designer:innen, Nachhaltigkeitsexpert:innen, Unternehmen und weitere Interessierte sind eingeladen, gemeinsam neue Ideen, Prototypen und Perspektiven zu entwickeln.

👉 Ziel: Konkrete Ansätze entwickeln, wie KI sinnvoll, verantwortungsvoll und mit echtem Mehrwert eingesetzt werden kann.

Sustainability Reporting for SMEs: Real Cases, Practical Steps

Mehr Infos & Anmeldung

KMU spielen eine zentrale Rolle in der nachhaltigen Transformation. Und doch stehen viele am gleichen Punkt: Wo anfangen? Was ist wirklich relevant? Und wie aufwändig ist das Ganze?

In dieser Session teilen 4 KMU ihre Erfahrungen mit freiwilligem Nachhaltigkeitsreporting. Das Format ist – als Roundtable – interaktiv: Teilnehmende können Fragen stellen, eigene Erfahrungen einbringen und zusammen diskutieren, wie Hürden überwunden werden können.

👉 Ziel: Hemmschwellen abbauen und zeigen, dass der Einstieg machbar ist. Die Community an engagierten KMU vergrössern.

Vom Reden und Handeln – gemeinsam

Die Zurich Climate Week steht für eine Haltung, die wir teilen: Dringlichkeit mit Optimismus verbinden. Nicht nur über Probleme sprechen, sondern konkrete Lösungen vorantreiben. Gemeinsam Verantwortung tragen – und dabei Wirkung entfalten.

Gerade in einem Umfeld, in dem Unsicherheiten zunehmen und Prioritäten sich verschieben, ist es umso wichtiger, dran zu bleiben. Nachhaltigkeit ist kein kurzfristiger Trend – sondern ein langfristiges Commitment. Und gleichzeitig eine Chance: für Innovation, für neue Geschäftsmodelle, für echte Differenzierung – für neue Lebensqualität.

Was wir dafür brauchen, sind mehr Räume für Austausch. Mehr Transparenz. Und mehr Mut, auch Unfertiges zu teilen.

Die Zurich Climate Week schafft genau solche Räume. Wir freuen uns, ein Teil davon zu sein.

The application does one - rather complicated - task, with lots of business logic. There was no way we could rewrite it to include it directly into the website code. And because the application comes with its own Javascript and CSS, we decided to use an iframe to embed the application with clean isolation.

The company maintaining that application provided us with a version - running as a Docker container - where they had stripped all extra elements like the navigation, so that it would visually fit within the website. There was however no way for us to customise anything within the application.

iframe security

The promise of an iframe is to keep a clean security boundary between embedding page and embedded content. This means that it is by design not possible to call Javascript across the boundary.

Because injecting iframes could potentially trick a user into submitting data to an attacker (clickjacking), as the iframe may be from a different origin than the main page. Thus, to even render the iframe, the browser checks the Content-Security-Policy (CSP) HTTP header. That header has a field frame-src to control what may be included as an iframe. With this, I allowed the domain of the application to be included in iframes.

Content-Security-Policy: frame-src https://my-embed.com;

But not only does the including page need to allow an iframe. The page to be embedded also needs to allow being included with the frame-ancestors attribute of the CSP header. As we run the application Docker image under our control, I was able to add that header in the proxy that runs before the Docker image:

Content-Security-Policy: frame-ancestors https://my-website.com;

Several things to note:

• If you have other CSP rules, merge them with the rules, nginx will overwrite the header and not add to it
• Both options also support "self" to allow embedding resp. being embedded with the same webserver
• Prior to the CSP becoming a standard, there was an unofficial header X-Frame-Options, which is still supported by browsers
• Content-Security-Policy must be an actual HTTP header, <meta http-equiv=”...”> is ignored for Content-Security-Policy (and also ignored for X-Frame-Options).

Size of the iframe element

Now we get to the weird parts. To prevent multiple scrollbars, we need the iframe element to be exactly big enough for the embedded page. If it is too small, there is an additional scrollbar (or hidden content). If it is too large, there is odd whitespace.

The size of the element needs to be set on the iframe, owned by the parent. The dimensions of the content are however only known by the embedded application. HTML / CSS do not provide any means to let the parent page declare that it wants the iframe to have the “necessary size”.

We ended up with a really convoluted way, which seems the only way to achieve this: sending messages from the child page to the parent. This problem spawned dedicated javascript libraries like iframe-resizer. We ended up reimplementing the logic in the React application, as it was so small that a dedicated library felt like overkill. Following the tutorial at iframe-height (which also has some interesting background on the discussion about iframes in the Whatwg), we came up with this code for the containing website:

// register an event listener for messages
window.addEventListener('message', receiveMessage, false);

// handle a message
function receiveMessage(event) {
    const origin = event.origin || event.originalEvent.origin;
    // we configure the expected domain to allow for this additional sanity check
    if (expectedDomain !== origin) {
      return;
    }
    if (!event.data.request || 'iframeResize' !== event.data.request) {
      return;
    }
    // the id is known in the js class. we need to find the element that needs to be resized
    const iframe = document.getElementById(`iframe-${id}`);
    if (iframe) {
      // pad the height a bit to avoid unnecessary tiny scrolling
      iframe.style.height = (event.data.height + 20) + 'px';
      // width could be handled the same way if necessary - in our case the width is fix
    }
}

Now we need to make the embedded content send a message with its height. The Javascript for that is a bit verbose to allow for different browsers, but not complicated either:

(
    function(document, window) {
      if (undefined === parent || !document.addEventListener) {
        return;
      }
      function init() {
        let owner = null;
        const width = Math.max(document.body.scrollWidth, document.body.offsetWidth, document.documentElement.clientWidth, document.documentElement.scrollWidth, document.documentElement.offsetWidth);
        const height = Math.max(document.body.scrollHeight, document.body.offsetHeight, document.documentElement.clientHeight, document.documentElement.scrollHeight, document.documentElement.offsetHeight);
        if (parent.postMessage) {
          owner = parent;
        } else if (parent.contentWindow && parent.contentWindow.postMessage) {
          owner = parent.contentWindow;
        } else {
          return;
        }
        owner.postMessage({
          'request' : 'iframeResize',
          'width' : width,
          'height' : height
        }, '*');
      }

      if (document.readyState !== 'loading') {
        window.setTimeout(init);
      } else {
        document.addEventListener('DOMContentLoaded', init);
      }
      // this is needed to also adjust the iframe if something (e.g. the Javascript of the application) changes the size of the iframe without an actual page reload.
      const observer = new ResizeObserver(init);
      observer.observe(document.body);
    }
  )(document, window);"

iframes with same origin

If the iframe comes from the same origin (= domain) as the parent page, Javascript can cross the boundary. From parent to child, there is a contentWindow property on the iframe element. From child to parent, there is window.parent. With same origin, those elements expose all things the window usually has. For different origins, they only expose the function postMessage for the secure separation.

Injecting content with Nginx

Remember how I said we can’t modify the application? That still holds true. If we would have loaded both applications from the same domain, we could have had the parent page add a listener inside the iframe to directly update dimensions as needed. But the application contained absolute paths for its assets, so providing it from a subfolder of the same domain would have been tricky and we had to run it on a separate domain.

I ended up injecting the above snippet of Javascript in the Nginx proxy that sits in front of the Docker container:

proxy_set_header Accept-Encoding ""; # make sure we get plain response for substitution to work
...
sub_filter_last_modified on;
sub_filter "</body>" "<script language='javascript'>${script}</script></body>";
sub_filter_once on;
...
proxy_pass https://my-embed.com$request_uri;

Now the embedded iframe communicates its size to the containing page, which adjusts the iframe size accordingly.

(Note that Nginx does not execute these statements in order. The sub_filter instructions apply to the response, wihle proxy_set_header and proxy_pass apply to the request.)

Alternatives

Web Components are a more lightweight solution to combine separate sources into one website. If what you need to integrate is just an element and not a whole application, they might be a better fit. My collegue Falk wrote about Web Components last week.

Bonus: Access control for the iframe content

Because the application is not under our control, we need to manage access to it. We told the supplier of the application to remove access control and simply allow items to be created and edited by ID. Of course, this means that the application must never be directly exposed to the internet, but only reachable through the proxy.

On the embedding side, we track which user is allowed what ids, and have Nginx do a pre-flight check against the website to get the access decision:

# at the beginning of the location for the main request to the embeded application
auth_request /auth;

location /auth {
    # preflight authorization request with symfony
    fastcgi_pass phpfcgi;
    include /usr/local/openresty/nginx/conf/fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /app/public/index.php;
    # forward the original request URI to allow our main application to verify access to the specific resource
    fastcgi_param REQUEST_URI /embed-check$request_uri;
    # body is not forwarded. we have to remove content length separately, otherwise PHP-FPM will wait for the body until the auth request times out.
    fastcgi_pass_request_body off;
    fastcgi_param CONTENT_LENGTH "";
    fastcgi_param CONTENT_TYPE "";
    internal;
}

If the call at /embed-check/... returns a 2xx status, Nginx continues with the request, otherwise it returns the response with the status code to the client, allowing for example to redirect to the login page. In my case, i return an empty response with status 204 if the user is allowed to access the specific resource.

On Symfony side, I use Symfony security to make sure the user is logged in. And then parse the path to know which item in the application the request wants to access, and check if the user has access. This leaks knowledge about the URL design of the embedded application, which is not avoidable for granular access control.

Here are practical techniques to prevent it.

Session Hygiene

Start a fresh session for each task. This is the simplest technique and the easiest to get right. If earlier research is needed, write it into a temporary handoff file and let a new session pick up from there.

Streamline Tool Calling

Every tool call adds tokens to the context. Poorly built tools add a lot of them. To keep the context lean:

• Choose tools and MCPs that are well built and optimize token usage
• Make sure via prompting that the right tools are used from the start

A single bloated tool response can waste more context than an entire conversation turn.

Subagents

Agents can spawn other agents that run in their own context. This isolates work and keeps the parent context clean. It helps most when building large features where individual parts are independent.

The easiest way to use subagents is to prompt something like:

Split the current plan into tasks, use a subagent for each task.

Persistent Tasks

I built an MCP for Claude Code called deliverables-mcp that lets an agent create persistent tasks per codebase. Tasks are stored in .claude/deliverables.jsonl and persist across sessions.

This allows:

• Starting a new session before implementing each task
• Running subagents in parallel based on tasks dependencies
• Restarting a failed task in a clean session

The tool replaces Claude Code's internal tasks and is deliberately called "deliverables" for two reasons:

1. To avoid confusing the agent with two tools both called "tasks"
2. Deliverables are typically larger than just a task, which is a sweet spot for AI agents. Not so small that handoff cost dominates, but small enough that context problems are rare.

You can check out deliverables-mcp on GitHub.

Ein Artikel der Initiator*innen dieses Projekts, veröffentlicht in der neuesten Ausgabe der Revue Médicale Suisse, zieht nun eine erste Bilanz ein Jahr nach der öffentlichen Lancierung.

Ein offizielles Angebot statt fehlerhafter Antworten online

Die medizinische Grundversorgung, ein zentraler Pfeiler eines funktionierenden Gesundheitssystems, steht zunehmend unter Druck, selbst in Städten. Wenn Patient*innen ihre Hausärzt*innen nicht schnell erreichen können, suchen sie oft im Internet nach Antworten. Die Informationen, die sie dort finden, sind jedoch häufig ungenau oder sogar potenziell gefährlich.

In diesem Kontext kann eine gut konzipierte KI-Lösung helfen, die richtige Information zur richtigen Zeit bereitzustellen.

Deshalb haben wir die HUG bei der Entwicklung eines RAG-basierten Chatbots (Retrieval Augmented Generation) unterstützt. ConfIAnce ist nicht der erste Chatbot für Patient*innen. Er unterscheidet sich jedoch durch seine institutionelle Wurzeln, die Nutzung lokal validierter medizinischer Inhalte sowie durch Kontrollmechanismen, die die Zuverlässigkeit der Antworten sicherstellen.

Um Sicherheit zu gewährleisten, integriert das System mehrere Kontrollmechanismen, darunter Matching, Groundedness, Harmfulness, automatisierte Tests und semantisches Routing.

Qualitätssicherung durch Kontrolle des Systems

Eine zentrale Herausforderung besteht darin, die Kontrolle über das System zu behalten. Dafür braucht es geeignete Monitoring-Funktionen.

Automatisierte Tests prüfen sämtliche Antworten des Chatbots auf ihre faktische Übereinstimmung mit der Wissensbasis.

Zusätzlich sorgt ein von Administrator*innen anpassbares Routing dafür, dass Fragen gefiltert und bei Bedarf unter menschlicher Aufsicht weitergeleitet werden. Sie können den Chatbot zudem sofort offline nehmen, falls ein Fehlverhalten vermutet wird.

Themen, über die häufig gefragt wird, aber in den Ausgangsdokumenten noch wenig behandelt werden, werden identifiziert und weiter ausgebaut. So wird die Wissensbasis im Rahmen eines kontinuierlichen Verbesserungsprozesses erweitert.

Selbst das beste Tool bringt nur etwas, wenn es genutzt wird

Damit Patient*innen den Chatbot tatsächlich verwenden, haben die HUG eine öffentliche Informationskampagne gestartet. Ziel war es, das Tool bekannt zu machen und gleichzeitig realistische Erwartungen zu setzen.

ConfIAnce ist kein medizinisches Gerät und ersetzt keinen Arztbesuch. Vielmehr ist er ein Informationsangebot, das Fragen zu den häufigsten chronischen Erkrankungen bei Erwachsenen beantwortet.

Im Februar 2025 ging ConfIAnce in der Beta-Version online. Zwischen Anfang Februar und Ende Oktober 2025 haben 3’823 Nutzer*innen mit dem Chatbot interagiert. Daraus entstanden 5’969 Gespräche und 11’781 Fragen, im Durchschnitt etwa zwei Fragen pro Gespräch.

Die direkt im Chatbot abgegebenen Rückmeldungen sind zu 75 % positiv.

Hohe Akzeptanz für einen etwas anderen Chatbot

Chatbots im Gesundheitsbereich werden von Patient*innen meist gut angenommen, vor allem wegen ihrer ständigen Verfügbarkeit und der einfachen Nutzung. Studien zeigen jedoch auch wiederkehrende Probleme: eine uneinheitliche Qualität der Antworten sowie mangelnde Transparenz bei den verwendeten Quellen.

Genau hier unterscheidet sich ConfIAnce von vielen anderen medizinischen Chatbots.
Der Chatbot wurde entwickelt, um die Beziehung zwischen Patientinnen und Ärzt\innen zu unterstützen, nicht zu ersetzen. ConfIAnce entlastet Ärzt*innen in der Grundversorgung und schafft ihnen mehr Zeit für die menschliche Seite ihres Berufs.

Die Autorinnen des Artikels in der Revue Médicale Suisse betonen zudem, dass der Chatbot, der im spezifischen Kontext der HUG und ihrer Dokumente entwickelt wurde, auch in anderen institutionellen Umgebungen eingesetzt werden kann. Damit ein solches Projekt erfolgreich ist, braucht es zunächst hochwertige Daten, wie sie hier zur Verfügung standen. Darüber hinaus ermöglichen Kontrollmechanismen, automatisierte Tests und Nutzer\innen-Feedback eine kontinuierliche Verbesserung – und sorgen für Sicherheit und Relevanz, die Vertrauen schaffen.

Unsere Reise zur Barrierefreiheit folgte vier Hauptschritten: automatische Scans und Quick-Fixes, Tastaturnavigation, Optimierung für Mobile-Zoom und anschliessend für den Screen-Reader.

Automatische Scans und Quick-Fixes

Wir begannen mit automatisierten Accessibility-Tests mithilfe von Browser-Erweiterungen wie IBM Equal Access Accessibility Checker und axe DevTools. Diese Tools halfen uns, häufige Probleme zu identifizieren: fehlende Labels, unzureichender Farbkontrast, unsauberes semantisches HTML und fehlende ARIA-Attribute. Obwohl automatisierte Scans nur etwa 40% der Accessibility-Probleme erkennen, boten sie eine solide Grundlage für unsere Arbeit.

Tastaturnavigation

Eine korrekte Tastaturnavigation ist grundlegend für die Barrierefreiheit. Sicherzustellen, dass die grundlegende Tab-Navigation in der gesamten App funktioniert, ist relativ einfach. Komplexere Komponenten wie Tabs, Menüs und Modals erfordern jedoch erweiterte Tastaturinteraktionen: Pfeiltasten, Escape-Handling und Fokus-Management gemäss den offiziellen W3C-Richtlinien. Nutzer*innen, die auf Tastaturnavigation angewiesen sind, erwarten diese spezifischen Muster. Wenn davon abgewichen wird, führt das zu Verwirrung und Frustration. Anstatt diese Muster von Grund auf neu zu implementieren, nutzten wir Bits UI, eine Headless-UI-Bibliothek, die diese Accessibility-Richtlinien korrekt umsetzt.

Über einzelne Komponenten hinaus implementierten wir Fokus-Loops und Fokus-Wiederherstellung auf Anwendungsebene, damit Nutzer*innen beim Wechsel zwischen verschiedenen Bereichen der Chat-Oberfläche stets orientiert bleiben.

Optimierung für Mobile-Zoom

Während User-Tests für meinplatz.ch mit Nutzer*innen mit Behinderungen beobachteten wir etwas Auffälliges: Viele navigieren auf Websites auf mobilen Geräten mit 200% oder mehr Zoom und halten ihre Geräte nur etwa 10 cm vor die Augen. Diese Erkenntnis zeigte eine kritische Lücke in den meisten Chatbot-Implementierungen auf.

Die meisten Chatbots verwenden Elemente mit fixer Position: ein Chat-Input am unteren Rand und häufig eine Kopfzeile am oberen Rand. Wenn Nutzer*innen stark hineinzoomen, können fixierte Elemente den gesamten Viewport einnehmen und die Oberfläche unbenutzbar machen. Leider ist es in Browsern nicht möglich, das Zoom-Level zuverlässig zu erkennen. Unsere Lösung: Wir verwenden den Intersection Observer, um zu erkennen, wenn Header oder Footer mehr Platz einnehmen als erwartet. In diesem Fall entfernen wir ihre fixe Positionierung dynamisch, um die Nutzbarkeit wiederherzustellen.

Screen-Reader-Erfahrung

Barrierefreiheit für Screen-Reader entsteht nicht automatisch, sie erfordert sorgfältiges Design. Wir konzentrierten uns darauf, klaren Kontext durch eine saubere Seitenstruktur (Landmarks und Überschriften) bereitzustellen. So verstehen Nutzer*innen jederzeit, wo sie sich befinden und was gerade passiert, und erhalten Shortcuts zu den wichtigsten Bereichen der App.

Kontext bereitstellen

Wir implementierten eine umfassende Outline-Struktur mit Landmarks für die Hauptnavigation, die Einstellungen und die Eingabebereiche. Jede Nachricht enthält korrekte Überschriften und Labels. Zusätzlich haben wir nach dem Chat-Input (am unteren Seitenrand) einen Skip-Link eingefügt, der Nutzer*innen hilft, schnell zum Seitenanfang zurückzukehren.

Herausforderungen mit Web Components

Die Arbeit mit Web Components brachte eigene Herausforderungen mit sich. VoiceOver reagiert besonders empfindlich darauf, wie Bibliotheken implementiert sind. Wir arbeiteten eng mit dem Bits-UI-Team zusammen (das sehr schnell auf Bug-Reports reagierte) und implementierten beispielsweise lokale Portals für Dropdown-Menüs, um Navigationsprobleme mit VoiceOver zu vermeiden.

Umgang mit Ankündigungen

Eine der schwierigsten Herausforderungen war das Management von VoiceOver-Ankündigungen, wenn mehrere Ereignisse gleichzeitig auftraten. Da das Queueing von Ankündigungen nicht zuverlässig funktioniert, haben wir Ereignisse sorgfältig sequenziert und zusammengehörige Ankündigungen zusammengeführt. Wenn Nutzer*innen zum Beispiel „Alle Optionen auswählen“ in einer Liste anklicken, würden normalerweise einzelne Ankündigungen für jede Option ausgelöst und sich gegenseitig überschreiben. Stattdessen brechen wir diese einzelnen Ankündigungen ab und ersetzen sie durch eine einzige klare Meldung, die alles zusammenfasst (alle Elemente ausgewählt oder abgewählt, auf die vordefinierte Auswahl zurückgesetzt usw.).

Da der Chat eine SPA ohne Seiten-Reloads ist, war es zudem wichtig, alle Änderungen anzukündigen, die nur visuell sichtbar sind, zum Beispiel: Wechsel zwischen Light- und Dark-Mode, Sprachwechsel usw.

Chat-Flow für Screen Reader

Wir haben die Chat-Erfahrung speziell für Screen-Reader-Nutzer*innen gestaltet:

• Das Eingabefeld enthält sowohl einen Placeholder als auch ein aria-label mit dem Seitentitel. Dadurch wird beim Laden der Seite Kontext bereitgestellt, da das Eingabefeld automatisch fokussiert wird und Nutzer*innen den initialen Seiteninhalt überspringen.
• Wenn eine Antwort generiert wird, kündigen wir dies klar an und geben damit dasselbe Feedback wie bei einer visuellen Ladeanzeige.
• Sobald eine Antwort bereit ist, wird sie ohne Markdown-Formatierung vorgelesen (kein Kursiv, keine Links usw.), um einen natürlichen Lesefluss zu gewährleisten.
• Nach dem Vorlesen einer Antwort weisen wir darauf hin, dass Nutzer*innen direkt eine weitere Frage stellen oder zu den Optionen der letzten Nachricht navigieren können, um Feedback zu geben oder Referenzen anzusehen. Wir fügen diesen interaktiven Abschnitt der letzten Nachricht dynamisch zur Dokument-Outline hinzu und schaffen damit einen schnellen Navigations-Shortcut.
• Der Chat-Verlauf ist als Artikel mit Labels strukturiert, sodass frühere Konversationen leicht navigierbar sind.

Selbst ausprobieren

Du kannst diese Verbesserungen mit Alva erleben, dem Chatbot der Verwaltung Basel-Stadt. Versuche, mit VoiceOver (MacOS) oder NVA (Windows) zu navigieren, nur deine Tastatur zu verwenden oder auf einem mobilen Gerät stark hineinzuzoomen.

Eine fortlaufende Reise

Unser nächstes Ziel ist es, automatisierte Accessibility-Tests in unsere CI-Pipeline zu integrieren. Wie bereits erwähnt, erkennen automatisierte Scans jedoch nur rund 40 % der Accessibility-Probleme. Das bedeutet, dass wir weiterhin jede neue Funktion sorgfältig planen und manuell testen müssen. Nichts ersetzt menschliches Testen, wenn es um Barrierefreiheit geht. Automatisierte Tools können fehlende Labels oder Kontrastprobleme markieren, aber sie können nicht beurteilen, ob eine Oberfläche tatsächlich für jemanden nutzbar ist, der mit Screen-Reader oder Tastatur navigiert.

Barrierefreiheit ist eine fortlaufende Reise, kein Ziel. Wir setzen uns dafür ein, LiipGPT für alle nutzbar zu machen, und werden unseren Ansatz kontinuierlich auf Basis von Praxisfeedback weiterentwickeln.

Brauchst du Unterstützung bei deiner Accessibility?

Wir bieten Accessibility-Audits an, um Probleme in deinen Anwendungen zu identifizieren und zu beheben. Wenn du die Barrierefreiheit deines Produkts verbessern möchtest, kontaktiere uns, wir helfen gerne weiter.