Tag 11: KI-Architektur verstehen: Warum drei Anbieter keine drei Lösungen sind

Marc

Eine Mitarbeiterin fragt den neuen internen KI Assistenten, wie lange sie eine bestimmte Spesenabrechnung aufbewahren muss. Sie bekommt Sekunden später eine extrem flüssig formulierte Antwort, mit Paragrafen, Quellenangaben und juristischem Tonfall. Die Antwort klingt absolut überzeugend, ist aber schlichtweg falsch, weil das hinterlegte Merkblatt im Dokumentenindex acht Monate alt ist. Niemand merkt es, und die Buchhaltungsunterlagen werden vorzeitig vernichtet.

Stefan

Und das Entscheidende an dieser Szene ist: Das war kein technischer Softwarefehler des Sprachmodells. Das war eine Architekturentscheidung, die drei Monate vorher am Reißbrett gefallen ist, und zwar völlig nebenbei. Herzlich willkommen zu unserem heutigen Podcast der Graduate School of Applied Technology and Management in Zürich. Wir begleiten heute den elften Kurstag im AI Business Specialist Training.

Marc

Mein Name ist Marc. Ich kenne den Schweizer Arbeitsmarkt aus unzähligen Gesprächen mit Personalverantwortlichen und Führungskräften, und ich sehe täglich, wo KI Vorhaben aufgleisen und woran sie in der Realität scheitern. Mir gegenüber sitzt Stefan, unser KI Experte an der GAT. Stefan, unser Thema heute lautet: Lösungsansätze aus Bausteinen zusammensetzen. Und die Kernbotschaft des Abends bringt es auf den Punkt: Ein Lösungsansatz wird nicht erfunden, sondern zusammengesetzt.

Stefan

Genau so ist es. Wer heute im Büro oder in der Prüfung eine Stunde lang nach kreativen Ideen sucht, hat die Methodik noch gar nicht verstanden. Es gibt einen überschaubaren Vorrat an Bausteinen, aus denen sich im Grunde fast jede Unternehmenslösung bauen lässt. Wer diesen Vorrat kennt, skizziert drei unterscheidbare Lösungsansätze in zwanzig Minuten, statt ziellos zu brainstormen.

Marc

Lass uns direkt bei dem Fehler ansetzen, den wir in der Praxis am häufigsten beobachten. Viele Teams behaupten stolz, sie hätten drei verschiedene Lösungsansätze verglichen. Wenn man dann in die Unterlagen schaut, steht da: Variante eins ist OpenAI, Variante zwei ist Aleph Alpha, und Variante drei ist Azure OpenAI.

Stefan

Das ist der Klassiker schlechthin. Das sind nämlich gar keine drei Lösungsansätze, sondern das ist ein einziger Lösungsansatz mit drei verschiedenen Preisschildern und Anbieternamen! In der eidgenössischen Berufsprüfung, speziell in Prüfungsteil eins bei der zwingenden Handlungskompetenz C3, ist das der schnellste Weg, durchzufallen. Die Experten wollen keine Einkaufsliste sehen, sondern Architektur.

Marc

Was genau verlangt denn die Prüfung und das Qualifikationsprofil bei der Handlungskompetenz C3? C3 heißt ja KI basierte Lösungsansätze entwickeln. Es ist eine von vier Pflichtkompetenzen in Prüfungsteil eins, der mündlich ist, 45 Minuten dauert und die Hälfte der Gesamtnote ausmacht.

Stefan

Richtig. Und C3 stützt sich direkt auf das eidgenössische Modul 618 ab. Dieses Modul verlangt wörtlich: verfügbare Produkte und Technologien zu vergleichen, Fachpersonen einzubinden und Zwischenergebnisse durch Rückmeldungen zu verbessern. Es geht also um das systematische Abwägen von Alternativen. Die Experten fragen dich in der mündlichen Prüfung: Welche Ansätze hast du verglichen, warum hast du dich für diesen entschieden, welchen Nachbarn hast du verworfen, und auf welche Annahme wettet deine Empfehlung?

Marc

Das ist der direkte Übergang von Tag 10 zu Tag 11 im AIBS Programm. An Tag 10 haben wir den Entwicklungsprozess, die Marktanalyse und die Produktvorauswahl behandelt. Heute, an Tag 11, nehmen wir das Anforderungsdokument von Tag 9 und bauen daraus die eigentliche Blaupause. Und zwar so konkret, dass am morgigen Samstag beim Prototyping Sprint mit Marcus Kuhn direkt gebaut werden kann.

Stefan

Bevor wir ein einziges Produkt oder Modell auswählen, müssen wir immer erst vier fundamentale Fragen der Lösungsarchitektur beantworten. Erstens: Welche Fähigkeit brauchen wir, und auf welcher Technikstufe? Zweitens: Woher kommt das Wissen, in welchem Zustand ist es, und wer pflegt es? Drittens: Wer entscheidet wann, wie sieht die Interaktion aus, und wo liegt die Eskalationsgrenze? Und viertens: An welche bestehenden Systeme schließen wir über welche Touchpoints an?

Marc

Lass uns bei der ersten Frage anfangen, der Fähigkeitsleiter. Wir unterscheiden in der Praxis vier Stufen der Fähigkeit, je nachdem, wie tief wir in die Technik eingreifen müssen. Stufe eins ist Prompting mit Anweisung, Beispielen und Formatvorgabe. Das dauert Tage und löst bereits viele einfache Aufgaben. Stufe zwei ist Retrieval, also RAG aus einer eigenen Wissensbasis. Das dauert zwei bis sechs Wochen und ist der Standard für Unternehmenswissen.

Stefan

Stufe drei ist die Feinabstimmung, also Fine Tuning, bei der wir das Modell auf eigenen Daten nachschulen. Das lohnt sich für Verhalten, Tonalität und feste Ausgabeformate, oder wenn das Volumen so riesig ist, dass ein kleineres feingetuntes Modell drastisch Kosten spart. Und Stufe vier ist der autonome Agent mit Werkzeugaufrufen, der selbstständig mehrstufige Pläne verfolgt.

Marc

Bei Stufe vier erleben wir derzeit enormes Agent Washing am Markt. Viele Berater verkaufen Agenten, wo ein ganz einfacher Workflow reichen würde. Anthropic hat dazu in ihrem Leitfaden Building Effective Agents sehr klar festgehalten: Ein Workflow ist eine vorab im Code festgelegte Abfolge von Modell und Werkzeugaufrufen. Du besitzt den Kontrollfluss. Ein Agent hingegen wählt seine Schritte dynamisch selbst. Du besitzt nur das Ziel. Wann immer der Weg vorab beschreibbar ist, ist ein Workflow billiger, schneller, robuster und viel besser zu testen.

Stefan

Exakt. Und um das alles extrem systematisch und praxistauglich zu machen, nutzt die GAT an Tag 11 die Bausteinmethodik. Wir haben einen Katalog aus sechs Familien mit jeweils vier Bausteinen, geordnet entlang des Weges der Daten durch das System. Sechs mal vier macht vierundzwanzig Entscheidungen, die immer wiederkehren.

Marc

Gehen wir diese sechs Familien einmal Schritt für Schritt durch. Was verbirgt sich hinter den einzelnen Familien und ihren jeweils vier Bausteinen?

Stefan

Sehr gerne. Familie A ist der Verarbeitungskern. Die Frage lautet: Was denkt in dieser Lösung? A1 ist das klassische Regelwerk, wenn Logik bekannt und starr ist. A2 ist das klassische Machine Learning Modell für historische Daten mit klarer Zielgröße. A3 ist das Sprachmodell mit Anweisung, aber ohne Firmenwissen. Und A4 ist das Sprachmodell mit Retrieval auf eigenen Dokumenten.

Marc

Familie B ist die Wissensquelle: Woher kommt das Wissen, mit dem gedacht wird? B1 ist der Dokumentenindex mit Weisungen, Handbüchern und Protokollen. B2 ist das Fachsystem oder die Datenbank mit strukturierten Werten. B3 ist die Live Schnittstelle für aktuelle Bestände. Und B4 ist der Mensch als Quelle, wenn das Wissen nirgends aufgeschrieben ist, sondern in Köpfen sitzt.

Stefan

Dazu gibt es ein hervorragendes Praxisbeispiel aus der Schweiz: Den Kundendienst Chatbot der SBB. Die SBB hat kein eigenes Basismodell trainiert. Sie nutzt ein gekauftes Sprachmodell, kombiniert mit Retrieval auf einer eigenen, sauber abgegrenzten Wissensbasis aus sbb.ch und internen Quellen. Sie wählte also Baustein A4 mit B1. Fähigkeit zugekauft, Wissen und Grenzen im eigenen Haus behalten. Das hält das Basismodell jederzeit austauschbar!

Marc

Weiter geht es mit Familie C: Der Datenweg. Wie kommen die Daten dorthin? Hier knüpfen wir direkt an den Daten Audit von Tag 6 an. Baustein C1 ist der nächtliche Import für große Mengen, wenn tagesaktuell reicht. C2 ist der Ereignisstrom für Reaktionen in Echtzeit. C3 ist der Abruf auf Anfrage per API, erst wenn jemand fragt. Und C4 ist die manuelle Übergabe durch Menschen für kleine oder heikle Bestände.

Stefan

Familie D ist der Integrationspunkt: Wo sitzt die Lösung im Arbeitsalltag? D1 ist die eigene, neue Oberfläche. D2 ist die Einbettung direkt im Fachsystem. D3 ist das Chattool wie Microsoft Teams oder Slack. Und D4 ist der Hintergrunddienst ohne Oberfläche.

Marc

Zu Familie D passt die Fallstudie von Morgan Stanley perfekt. Die Bank hat ihren KI Assistenten für Finanzberater nicht als separates Portal gebaut, sondern direkt in die täglichen Beraterwerkzeuge eingebettet, also Baustein D2. Das Bild dazu im Leitfaden ist fantastisch: Ein separates Portal ist wie eine Kantine im Nachbargebäude. Das Essen kann hervorragend sein, aber bei Regen geht niemand hin. Die Einbettung am Ort der Arbeit entscheidet über die reale Nutzung.

Stefan

Jetzt kommen wir zu Familie E: Das Mensch Maschine Muster. Wer entscheidet, und wann übernimmt ein Mensch? E1 ist vollautomatisch ohne Rückfragen. E2 ist Vorschlag mit menschlicher Freigabe. E3 ist Assistenz auf Abruf, wo der Mensch aktiv fragt. Und E4 ist Automatik mit definierter Eskalationsregel.

Marc

Familie E ist die mit Abstand mächtigste und kritischste Familie des ganzen Katalogs, weil sie über Haftung, Risiko und Akzeptanz entscheidet. Denke an den berühmten Rechtsfall Moffatt gegen Air Canada aus dem Jahr 2024. Ein Chatbot auf der Website der Airline gab einem Passagier eine falsche Auskunft zu Tarifen für Trauerfälle. Air Canada argumentierte vor Gericht, der Chatbot sei eine eigenständige Einheit und man hafte nicht für dessen Halluzinationen. Das Gericht stellte klar: Was auf eurer Website steht, habt ihr gesagt. Wer Stufe E1 wählt, wählt automatisch die volle Haftung für jede Ausgabe.

Stefan

Ein weiteres eindrückliches Beispiel für Familie E ist Klarna. Klarna hat im Kundendienst extrem schnell auf Vollautomatik umgestellt und öffentlich verkündet, hunderte Stellen einzusparen. Später korrigierte das Unternehmen öffentlich und baute menschliche Kapazität wieder auf. Die Durchschnittskennzahlen sahen gut aus, aber der Schaden lag in den Randfällen. Autonomie ist kein Schalter, den man einfach umlegt, sondern ein Schieberegler, den man im Betrieb steuert.

Marc

Schließlich Familie F: Die Absicherung. Woran merkt jemand, dass es funktioniert? F1 ist die Prüfregel vor der Ausgabe auf Format und Wertebereich. F2 ist die regelmäßige Stichprobe im laufenden Betrieb. F3 ist die Rückmeldung der Nutzenden über Feedbackknöpfe. Und F4 ist der Abnahmetest gegen das Anforderungsdokument aus Tag 9.

Stefan

Damit dieser Katalog kein trockenes Merkblatt bleibt, sondern zur praxistauglichen Methode wird, gelten drei eiserne Regeln. Regel eins: Ein Baustein je Familie, keine Enthaltung. Wer eine Familie leer lässt, hat die Entscheidung nicht vermieden, sondern sie nur unbewusst verschoben. Regel zwei: Je Ansatzpaar mindestens zwei Familien Unterschied. Zwei Ansätze, die sich nur in Familie A unterscheiden, sind eine Produktauswahl. Wir variieren vor allem Familie E den Autonomiegrad und Familie D den Integrationsort.

Marc

Und Regel drei ist der Schlüssel für die mündliche Prüfung: Zu jedem gewählten Baustein der verworfene Nachbar mit Grund! Du sagst im Fachgespräch nicht nur: Wir wählen Baustein A4. Du sagst: Wir wählen A4 Sprachmodell mit Retrieval auf dem Dokumentenindex B1. Verworfen haben wir A3 reine Anweisung, weil die Antworten aus unseren internen Weisungen belegbar sein müssen. Und verworfen haben wir B2 Fachdatenbank, weil unser Wissen in unstrukturierten Texten liegt. Dieser eine Satz zeigt den Experten sofort, dass du konzeptionell durchgearbeitet hast.

Stefan

Dazu nutzen wir die Kurznotation: A4 B1 C1 D3 E2 F1. Damit lässt sich ein kompletter Lösungsansatz in einer Zeile notieren. Und in Abschnitt 4 des Katalogs lernen wir die Kombinationsregeln. Bausteine lassen sich nämlich nicht beliebig mischen. Manche ziehen andere zwingend nach sich. A4 Sprachmodell mit Retrieval zieht B1 Dokumentenindex und F1 Prüfregel nach sich. Wer Vollautonomie E1 wählt, zieht zwingend F1 Prüfregel und F2 Stichprobe nach sich.

Marc

Und der Satz, der bis Tag 13 trägt: Autonomie ist nicht der Verzicht auf Kontrolle, sondern ihre Verlagerung in den laufenden Betrieb! Gleichzeitig zeigen die Kombinationsregeln, was sich absolut ausschließt: Vollautomatik E1 mit einem reinen Sprachmodell A3 ohne Wissensbasis ist fahrlässig. Manuelle Übergabe C4 mit Vollautomatik E1 ist eine Illusion. Oder Hintergrunddienst D4 mit Nutzerfeedback F3: Wo niemand hinschaut, gibt auch niemand Rückmeldung.

Stefan

Und das ist auch prüfungsseitig glasklar belegt! Modul 618 verlangt wörtlich: verfügbare Produkte und Technologien zu vergleichen sowie Fachpersonen einzubinden und Zwischenergebnisse durch Rückmeldungen zu verbessern. Der Bausteinkatalog ist die systematische Form genau dieses geforderten Vergleichs.

Marc

Sogar das offizielle Praxisbeispiel aus dem Modul 618 deckt sich wörtlich mit unserem ISA Desk Vergleich! Im Modul wird eine verbesserte Suchfunktion einem KI Assistenten gegenübergestellt. Bei uns im Katalog ist die einfache Suche A1 B1 C1 D2 E3 F3, während der KI Assistent A4 B1 C1 D3 E2 F1 entspricht. Zwei Ansätze, die sich in vier Familien unterscheiden. Das ist echte Wahlfreiheit!

Marc

Reden wir mal über den Punkt, an dem die meisten Teams in der Praxis schmerzhaft auflaufen. Das System gibt eine falsche Antwort, und sofort schreit alles: Das Modell halluziniert! Wir brauchen ein besseres Modell!

Stefan

Ja, der Reflex ist unausrottbar. Dabei zeigt die Erfahrung: In geschätzten 80 Prozent der Fälle ist nicht das Sprachmodell schuld, sondern der Abruf davor. Der Fehler passiert in den neun Stationen der Datenpipeline. Unvollständige oder veraltete Rohdaten, schlechtes Chunking und mangelhafte Indexierung zerstören die Trefferquote, bevor das Sprachmodell überhaupt ein einziges Wort erzeugt.

Marc

Gehen wir diese Pipeline mal durch. Sie geht ja von der Quelle über Extraktion, Bereinigung, Strukturierung, Index, Abruf, Kontextbildung und Ausgabe bis hin zum Protokoll. Wo sterben die Daten denn typischerweise?

Stefan

Meistens bei Station 4, der Strukturierung, Stichwort Chunking, und bei Station 6, dem Abruf. Wenn du ein PDF einfach stur alle 500 Zeichen durchschneidest, zerreißt du Sinneinheiten. Ein Satz wie "Dieser Entscheid wurde aufgehoben" steht dann plötzlich ohne den Kontext da, welcher Entscheid überhaupt aufgehoben wurde. Das Modell bekommt Müll gefüttert und liefert folglich Müll zurück. Die Lösung lautet kontextuelle Anreicherung vor der Einbettung, was Abruffehlschläge um bis zu 67 Prozent senkt.

Marc

Dazu kommt das wissenschaftlich nachgewiesene Phänomen Lost in the Middle von Liu und Kolleginnen aus dem Jahr 2023. Sprachmodelle nutzen Informationen am Anfang und am Ende eines langen Kontextfensters sehr zuverlässig. Wenn die entscheidende Stelle aber in der Mitte von zwanzig abgerufenen Dokumentenseiten liegt, übersieht das Modell sie schlichtweg. Mehr Kontext ist nicht besser. Wenige, präzise und per Reranking neu geordnete Textstellen schlagen riesige Kontextmengen jedes Mal.

Stefan

Und deshalb messen wir in modernen Architekturen zweistufig mit der RAG Triade. Wir trennen die Bewertung strikt auf.

Marc

Wie sieht diese Trennung konkret aus?

Stefan

Erstens: Kontextrelevanz. Haben wir überhaupt die richtigen Textstellen aus der Wissensbasis herausgesucht? Das misst die Güte des Abrufs. Zweitens: Verankerung, auch Groundedness genannt. Ist jede Aussage in der Antwort durch die abgerufenen Quellen belegt? Und drittens: Antwortrelevanz. Beantwortet der erzeugte Text tatsächlich die Frage des Nutzers?

Marc

Das ist extrem mächtig. Wenn die Verankerung schlecht ist, müssen wir am Prompting oder am Modell arbeiten. Wenn aber schon die Kontextrelevanz tief ist, brauche ich das Modell gar nicht anzufassen, sondern muss mein Chunking und mein Reranking in der Pipeline reparieren. Auswertungen zu Unternehmens Rollouts wie von IntuitionLabs belegen, dass fast die Hälfte aller Vorhaben genau an dieser fehlenden Qualitätsschicht scheitert.

Stefan

Richtig. Und unter Schweizer Recht ist das eine Haftungsfrage. Wenn deine Fachspezialistinnen ungeprüften Modell Outputs vertrauen, weil in der Pipeline Datenlücken verschleiert wurden, haftet am Ende das Unternehmen für den entstandenen Schaden.

Marc

Stefan, ich sehe in Lastenheften ganz oft den Satz: Wenn die Konfidenz des Modells unter 80 Prozent fällt, eskalieren wir an einen Menschen. Das klingt doch im ersten Moment völlig logisch, oder?

Stefan

Das ist einer der gefährlichsten Trugschlüsse überhaupt! Praxisauswertungen zeigen, dass KI Systeme bei Aktionen, die sich im Nachhinein als komplett falsch herausstellten, eine durchschnittliche Konfidenz von 0.87 hatten. Das System war sich also extrem sicher, während es monumentalen Unsinn gebaut hat. Ein Modell kann gleichzeitig völlig selbstbewusst und völlig falsch liegen. Wer Eskalation nur über eine Konfidenzzahl baut, rennt sehenden Auges in die Falle.

Marc

Deshalb arbeiten wir im AIBS Standard mit einer fünfzeiligen Eskalationsmatrix. Jede Zeile definiert: Welcher Fall, welcher Auslöser, wer übernimmt, wie schnell ist die Reaktionszeit, und woran messen wir es?

Stefan

Und da gehören mindestens zwei Regeln rein, die völlig unabhängig von irgendeiner Konfidenzzahl greifen! Erstens: Harte Themenregeln. Sensible Themen wie Kündigungen, Haftungsfragen oder Auszahlungen gehen nie vollautomatisch raus. Zweitens: Der ausdrückliche Wunsch der Kundin nach einem Menschen. Wenn jemand tippt "Ich möchte mit einer Beraterin sprechen", darf keine KI der Welt das ignorieren.

Marc

Das deckt sich exakt mit Artikel 14 des EU AI Acts zur menschlichen Aufsicht. Dort wird auch ausdrücklich der Automation Bias erwähnt, also die Neigung von Menschen, KI Ausgaben ungeprüft abzunicken. Wir verhindern das im Betrieb durch progressive Automatisierung.

Stefan

Progressive Automatisierung heißt: Wir starten auf Stufe E2 oder E3: Vorschlag mit Freigabe. Das System entwirft, der Mensch prüft und gibt frei. Währenddessen messen wir im Hintergrund mit einem Golden Dataset aus 200 bis 500 echten, geprüften Praxisfällen. Erst wenn die Trefferquote in einer bestimmten Fallklasse über Monate nachweisbar nahe einhundert Prozent liegt, schalten wir diese spezifische Klasse schrittweise auf Automatik um.

Marc

Stefan, lass uns zum Abschluss den Bogen zu unserem Mustercase schlagen, dem ISA Desk. Der ISA Desk ist ein interner Wissensassistent für Auskünfte zu Weisungen. Wie sieht der Baukasten aus, wenn wir die drei geforderten Lösungsansätze nebeneinanderstellen?

Stefan

Wir bauen drei Ansätze, die sich in ihren Bausteinen deutlich unterscheiden. Ansatz eins, die schlanke Variante: A1 B1 C1 D2 E3 F3. Eine klassische, regelbasierte Suchfunktion im bestehenden Fachsystem. Der Mensch fragt aktiv, die Rückmeldung kommt über Nutzerratings. Billig, schnell gebaut, aber geringe KI Wirkung.

Marc

Ansatz zwei, der Regelfall und unsere Empfehlung: A4 B1 C1 D3 E2 F1. Ein KI Assistent mit Retrieval auf dem Dokumentenindex, eingebettet direkt im Chattool Microsoft Teams. Das System macht einen Entwurf, der Mensch gibt frei, abgesichert durch eine Prüfregel auf Quellenangabe und Dokumentendatum. Das ist in wenigen Wochen baubar und bringt echte Entlastung.

Stefan

Und Ansatz drei, die ambitionierte Variante: A4 B2 C2 D4 E4 F2. Eine im Hintergrund mitlaufende Automatik an Datenbanken und Ereignisströmen, mit automatischer Eskalation und Stichproben im Betrieb. Teuer im Aufbau, aber skaliert ohne zusätzliche Personenzeit. Die drei Ansätze unterscheiden sich in vier, fünf und sechs Familien. Das ist perfekte Ansatzvielfalt für die Prüfung.

Marc

Und zu jedem Ansatz gehört die Wette, also die fundamentale Annahme, auf die der Ansatz setzt! Beim ISA Desk lautet die Wette für Ansatz zwei: Die zugrundeliegende Dokumentenbasis wird von den Fachabteilungen laufend gepflegt. Ist diese Annahme falsch, fällt der beste KI Assistent in sich zusammen, egal wie gut das Sprachmodell ist. Wer die Annahme nicht benennen kann, hat nicht entschieden, sondern nur gehofft.

Stefan

Genau das verlangt Prüfungsteil eins der Berufsprüfung für Handlungskompetenz C3. Wenn du in der mündlichen Prüfung deine drei Ansätze so vorträgst, die unterscheidende Familie nennst, deine Empfehlung begründest und die Wette benennst, hast du die volle Punktezahl auf sicher.

Marc

Und das Allerbeste ist: Diese Architektur ist die direkte Eingabe für den morgigen Prototyping Samstag mit Marcus Kuhn im Launchspace Zürich Altstetten! Wer heute Abend in der Projektwerkstatt bis 21:00 Uhr seine sechs Bausteine sauber definiert hat, kann morgen um Punkt 09:00 Uhr ohne Zeitverlust direkt mit dem Bauen des Prototyps beginnen.

Stefan

Besser kann man es nicht auf den Punkt bringen. Was heute Abend ausgewählt wird, ist der Bauplan für morgen früh. Und was wir heute als Validierung festlegen, wird an Tag 13 zu unserem zentralen Messinstrument in der Machbarkeitsprüfung. Fassen wir die Kernbotschaft noch einmal zusammen: Ein Lösungsansatz wird nicht erfunden, sondern aus sechs Entscheidungen zusammengesetzt.

Marc

Wer den Vorrat kennt, sucht nicht nach Ideen, sondern wählt begründet aus und kann jede Wahl gegen den Nachbarn verteidigen. Wir wünschen der ganzen Kohorte viel Erfolg beim heutigen Kurstag, eine produktive Projektwerkstatt ab 20:00 Uhr und morgen einen erfolgreichen Prototyping Sprint!

Stefan

Danke fürs Zuhören, und bis zur nächsten Folge unseres AIBS Podcasts!