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.

GovNL: Von Monaten zu Minuten beim Aufbau von Websites

GovNL kombiniert Open-Source-Drupal-Komponenten mit einem offenen Designsystem, um zahlreiche Websites der niederländischen Regierung zugänglich und skalierbar zu betreiben. Die Zeit für den Aufbau neuer Websites reduziert sich dadurch von etwa drei Monaten auf rund zehn Minuten. Beeindruckend, um es gelinde zu sagen. Das ist ein starkes Beispiel dafür, wie Design für Wiederverwendung in grossem Massstab funktionieren kann.

Europäische Kommission: Koordination ist der Schlüssel zur Skalierung

Die Europäische Kommission betreibt bereits 770 Websites und investiert stark in das Drupal-Ökosystem. Besonders aufgefallen ist mir, wie stark der Fokus auf Koordination liegt. Man muss sicherstellen, dass die richtigen Inhalte über den richtigen Kanal innerhalb dieser grossen Website-Landschaft veröffentlicht werden. Open Source Program Offices (OSPOs) wurden eingerichtet, um Open-Source-Strategien sowohl auf Regierungsebene als auch innerhalb von Organisationen voranzutreiben.

Website des Kantons Basel-Stadt und Alva: ein Blueprint für lokale öffentliche Verwaltungen

Kurz vor der Mittagspause war ich an der Reihe, die verschiedenen KI-Use-Cases vorzustellen, die wir für den Kanton Basel-Stadt umgesetzt haben. Der Kanton setzte mit dem Relaunch von bs.ch neue Standards: mit einem nutzerorientierten Design, einem themenbasierten Zugang statt interner Organisationsstruktur und Alva als erstem KI-basierten Chatbot für einen Schweizer Kanton. Der Tech-Stack basiert auf Open-Source-Komponenten, und Liip hat im Rahmen des Relaunches stark zu Open Source beigetragen. Wir verwenden Drupal als CMS, Nuxt/Vue, den blökkli-Editor für das Headless-Frontend und Elasticsearch für die Suche. Die Inhalte werden von einem departementsübergreifenden Redaktionsteam erstellt, das einer klaren Content-Strategie folgt.

KI zur Unterstützung der Öffentlichkeit und der Editor*innen

Der Vortrag war auch eine Gelegenheit, mehr als 18 Monate nach dem Go-Live Zahlen zu teilen. Heute beantwortet Alva über 10 000 Fragen pro Monat, mit durchschnittlich 1,36 Fragen pro Konversation und einem Wachstum von +44 % seit Alva 2.0. Dank API-Integrationen kann der Chatbot Fragen auf Basis von Echtzeitinformationen beantworten. Alva wird stark von internen Mitarbeitenden des Kantons sowie von der Öffentlichkeit genutzt. Der Chatbot zeigt und überprüft stets seine Quellen, was entscheidend ist, um Vertrauen aufzubauen.

Auf der Redaktionsseite arbeitet blökkli intensiv daran, Texte zu vereinfachen. Mit dem blökkli-Editor und integrierter KI können Editor*innen nun Lesbarkeitsanalysen durchführen, vorgeschlagene Vereinfachungen nebeneinander sehen und diese übernehmen oder anpassen. Alva und die KI-Funktionen auf bs.ch werden kontinuierlich weiterentwickelt, um Editor*innen und Bürger*innen vertrauenswürdige KI-Technologien bereitzustellen.

KI-gestützte Technologien in der französischen Regierung

Ein weiterer inspirierender Vortrag zeigte Use-Cases von KI auf der Plattform Services Publics+ der französischen Regierung. Mit über 140 000 geteilten Erfahrungen und mehr als einer Million Reaktionen nutzt das System KI-gestützte Technologien, um staatlichen Stellen dabei zu helfen, Feedback an Bürger*innen zu geben. Dazu gehören Speech-to-Text und Echtzeit-Zusammenfassungen als zentrale Technologien. C’est magnifique!

Die EU vertraut Open Source mehr denn je

Die Europäische Union hat den Website Evidence Collector eingeführt – ein Open-Source-Tool, das Websites auf Sicherheitsprobleme überprüft. Bemerkenswert ist, dass das Projekt unter der EUPL (European Union Public Licence) veröffentlicht wurde. Diese betont die Interoperabilität zwischen Ländern und Lizenzen und unterstützt mehrsprachige Zusammenarbeit. Ich frage mich, ob es in der Schweiz etwas Ähnliches gibt.

Mit Interoperable Europe bietet die EU ausserdem ein neues Portal mit einem hilfreichen Licensing Assistant. Damit kannst du Softwarelizenzen finden und vergleichen sowie mit einem Kompatibilitäts-Checker prüfen, ob verschiedene Open-Source-Lizenzen kombiniert werden können und ob rechtliche Komplikationen entstehen könnten.

Open Source zu nutzen reicht nicht - wir brauchen Champions

Zum Abschluss betonte Tiffany Farris von der Strategieberatung Palantir.net (nicht zu verwechseln mit Palantir Technologies), dass die Nutzung von Open Source gut ist, aber nicht ausreicht. Organisationen brauchen Champions, die Beiträge zur Community und die Gesundheit des Ökosystems aktiv vorantreiben. Design für Wiederverwendung sollte ein zentrales Prinzip sein. Aus US-Perspektive ist Beschaffung (Procurement) ein grosses Problem: Die Nutzung von Open Source wächst, aber Unterstützungsmechanismen oft nicht. Wenn Open Source als „kostenlos“ betrachtet wird, kann das dazu führen, dass Aufträge an Anbieter gehen, die ihre Arbeit zwar als Open Source vermarkten, aber kein nachhaltiges Ökosystem unterstützen. Sie schlug konkrete Anpassungen der öffentlichen Beschaffung im Sinne von „Public Money, Public Code“ vor, um das Ökosystem besser zu unterstützen. Ein wirklich inspirierender Abschluss für einen intensiven Tag voller Lernen und Austausch.

Wenn du tiefer in die Inhalte eintauchen möchtest, kannst du dir die Playlist der Präsentationen von Drupal4Gov EU 2026 ansehen.

We created a fully themeable chat UI that can be embedded in any website and has no effect on the parent page. Kanton Basel-Stadts Alva and RAMMS' Rocky AI are instances of that UI.

This blog post will show you what we learned about creating web components that do not influence the parent page. Here are the good, the bad and the ugly when working with web components.

The Good

These are the good parts of web components. They will lay the foundation for why you might use them.

Portability

Every system that can handle HTML can handle web components. A simple tag and a script will integrate it into any web framework. It doesn't even need to be a JavaScript framework.

<body>
  <your-webcomponent></your-webcomponent>
  <script src="path/to/your-webcomponent.js"></script>
</body>

Native Feel

IFrames are another way to embed UI into a page, and they are arguably easier to use. But the main difference is that web components feel more native to the page, since they directly integrate into the parent page's layout. This means you can use transparency, intrinsic sizing (size based on the web component's contents), and seamless event communication with the parent page.

Slots

With slots you can provide content that will be added at a specified point inside your web component.

In our chat UI, we used a slot to let integrators provide a custom loading spinner. This spinner needs to be visible immediately, before the full theme loads asynchronously.

Shadow DOM - Isolating Styles

A robust way to ensure that your styles do not affect the parent page is to use the Shadow DOM. Shadow DOM is a web component feature to add a boundary for styles. Styles applied inside the Shadow DOM never apply to the parent page.

Caveat: Inheritable CSS Properties

There is one exception to the isolation where CSS properties of the parent page apply to the web component.

These are the properties that pierce through the boundary:

• Inheritable CSS properties like color, font-family, line-height
• CSS custom properties like --my-var

In practice, we have found it helps to fully specify the common properties like fonts and color on every element. That way you will never be surprised by different styles on integration.

Vite

For bundling web components, we can highly recommend Vite. There are a lot of neat tricks you can apply while bundling. Here are the Vite features we used for our web component.

Inlining Assets

Vite's explicit inline handling feature allowed us to inline our external CSS files into the JS bundle.

import cssContentString from "./index.css?inline";

This feature will not only inline the raw content of the imported index.css. It will also resolve all CSS imports, apply PostCSS transforms, and even work with CSS preprocessors like SASS. While inlined CSS is not the most efficient for browsers to render, the benefit is that we can ship a single JS file.

Library Mode

The Vite library mode provides you with fine-grained control of how the bundle should behave. To enable the library mode just add the build.lib option in your Vite config.

The Bad

Not everything about web components is great though. Here are the bad parts.

SSR - Hard to Get Working

Server-side rendering will almost certainly not work. The rest of the page can still be rendered server-side, but the web component will only show up as a <your-webcomponent></your-webcomponent> tag. Its contents will only be rendered in the browser.

There is one experimental package by Lit Labs that tries to solve this, but we never tried it.

Tailwind - Not a Great Fit

Tailwind feels like a natural choice for web components, but it does not play well with them.

The core issue is twofold. First, Tailwind ships its own CSS reset (called Preflight), which overrides default browser styles. When injected into a page that does not use Tailwind, it potentially breaks the page. Shadow DOM could isolate this reset, but Tailwind is fundamentally not designed to work inside a Shadow DOM. Here is the discussion if you are interested.

There are some hacky workarounds, but we tried them and had no success getting them to work reliably.

Our recommendation is to only use Tailwind if you are guaranteed that the parent page also uses it, and then use web components without Shadow DOM.

The Ugly

Verbose Web Components API

The native web component API is verbose and hard to read. A simple counter component, for example, requires manually defining a class, attaching a shadow root, setting up innerHTML, and wiring event listeners in connectedCallback. This boilerplate adds up quickly. You can see examples of the API here.

Fortunately, web components make for a great compile target. Svelte and Vue directly support compiling to web components. React is a bit trickier, but totally doable as well. We used this approach for our chat UI, where the first iteration was built with React and the current one with Svelte.

Weird Quirks

Advanced web component features come with edge cases that no documentation warns you about. Even Svelte, which has excellent web component support, ships with a notable list of caveats.

We even hit an undocumented edge case with slots in Svelte: the bundle script must load after the component markup, or slotted content will not render. An ugly wrapper for slots fixes the problem, but quirks like this add up and slow you down.

Font Loading - Not Working Inside Shadow DOM

When authoring web components, you get into the habit of defining all stylesheet links etc. in the web component body. As you should, so they do not affect the parent page. But there is another annoying detail here: @font-face will not work when defined in the Shadow DOM. If your web component needs a custom font, you need to inject the font CSS into the parent page to make it work.

Conclusion

I do not want to end on this ugly note though. I really think there are cases where web components are the right choice, and in our case we would choose Svelte & web components again.

To help you get started, here is a Svelte starter template.

The City of Zurich publishes over 900 datasets as open data, spread across six different APIs. There's CKAN for the main data catalog, a WFS Geoportal for geodata, the Paris API for parliamentary information from the Gemeinderat, a tourism API, SPARQL linked data, and ParkenDD for real-time parking data. All public, all freely available. But until now, making an AI assistant actually use these APIs meant writing custom integrations for each one.

The MCP server wraps all six APIs into 20 tools that any MCP-compatible AI assistant can call directly. Ask "How warm is it in Zurich right now?" and it queries the live weather stations. Ask about parking availability, and it pulls real-time data from 36 parking garages. It also covers parliamentary motions, tourism recommendations, SQL queries on the data store, and GeoJSON features for school locations, playgrounds, or climate data. All through a single, standardized Model Context Protocol interface.

Hayal Oezkan built it in Python using FastMCP. One file for the server with all 20 tool handlers. The repo is on GitHub.

Deploying it on our side took very little effort. The server supports both stdio transport for local use (like in Claude Desktop or Claude Code) and SSE and HTTP Streaming for remote deployment. I packaged it with Docker, deployed it to our cluster, and now it's available as a remote MCP server that anyone can add to their AI tools without installing anything locally.

The natural next step was integrating this with ZüriCityGPT. It happened, just not quite in the direction I originally had in mind.

ZüriCityGPT already had its own MCP server at zuericitygpt.ch/mcp, exposing tools for searching the city's website content, "Stadtratsbeschlüsse" and looking up waste collection schedules. Instead of wiring the open data tools into ZüriCityGPT, I went the other way: the open data MCP server now proxies tools from the ZüriCityGPT MCP server. A lightweight proxy client connects to the remote server via streamable-http and forwards calls. The whole thing is about 40 lines of Python.

So now, when you connect to the Zurich Open Data MCP server, you get 23 tools in one place. The 21 original open data tools across six APIs, plus zurich_search for querying the city's knowledge base and zurich_waste_collection for waste pickup schedules (based on the OpenERZ API). One MCP endpoint, many services behind it.

A city employee builds something useful in the open, publishes the code, and within a day it's deployed and available to a wider audience. Open data and open source working together, exactly as intended.