Metas KI-Agent Muse hat nach dem Start rasch Aufmerksamkeit gefunden und Platz eins im Apple App Store erreicht. Zu den Nutzerzahlen kursieren unterschiedliche Angaben: In der Überschrift einer Meldung ist von 50.000 Nutzern in der ersten Woche die Rede, im Text derselben Meldung von über 500.000. Die Größenordnung bleibt damit unsicher – festhalten lässt sich lediglich, dass der Start außergewöhnlich viel Zulauf erzeugt hat.

Interessanter als die Zahl sind zwei Punkte, die kurz nach dem Launch öffentlich wurden. Sie berühren Fragen, die in Unternehmensprojekten mit KI-Bezug regelmäßig auftauchen: Woher kommt der Code, und was erledigt ein sogenannter Agent tatsächlich selbst?

Punkt eins: Herkunft des Codes

Meta räumt ein, dass Muse "stark inspiriert" vom Open-Source-Projekt OpenClaw ist. Dateinamen und Inhalte sollen teilweise nahezu identisch sein. Das ist mehr als eine Stilfrage. Open-Source-Software ist nicht gleichbedeutend mit frei verwendbar: Jede Lizenz knüpft die Nutzung an Bedingungen, von der Nennung der Urheber bis hin zur Pflicht, abgeleitete Werke unter derselben Lizenz zu veröffentlichen.

Wer fremden Code übernimmt – ob manuell oder über ein KI-Modell, das auf öffentlichen Repositories trainiert wurde – übernimmt potenziell auch diese Bedingungen. Bei Meta ist das ein Reputationsthema. Bei einem mittelständischen Unternehmen, das eine Anwendung ausliefert oder an Kunden weitergibt, kann daraus ein konkretes Rechtsrisiko werden.

Punkt zwei: Wie autonom ist der Agent?

Muse soll laut Produktversprechen unter anderem Anrufe für Nutzerinnen und Nutzer tätigen. Aus interner Kommunikation ergeben sich Hinweise, dass diese Anrufe stattdessen von Call-Center-Mitarbeiterinnen und -Mitarbeitern übernommen werden. Bestätigt ist der Sachverhalt nicht abschließend, die Berichterstattung stützt sich auf interne Unterlagen.

Das Muster ist nicht neu. Zwischen "das System kann das" und "das System macht das im Regelbetrieb allein" liegt häufig ein Stück menschliche Arbeit – als Fallback, zur Qualitätssicherung oder weil die letzten Prozent an Zuverlässigkeit technisch teuer sind. Problematisch wird es dort, wo dieser Anteil nicht kommuniziert wird. Denn Nutzerinnen und Nutzer treffen ihre Entscheidungen – etwa darüber, welche Daten sie preisgeben – auf Basis der Annahme, mit einer Maschine zu sprechen.

Was daraus für eigene Projekte folgt

Beide Punkte lassen sich in konkrete Anforderungen übersetzen, die sich in jedem Projekt stellen, in dem KI-Werkzeuge oder Agentensysteme eingesetzt werden.

Herkunft von Code klären

  • Lizenzprüfung als fester Schritt: Abhängigkeiten und übernommene Codefragmente sollten dokumentiert und auf ihre Lizenz geprüft werden – automatisiert im Build-Prozess, nicht erst beim Audit.
  • KI-generierten Code kennzeichnen: Wenn Assistenzsysteme im Einsatz sind, hilft eine interne Regel, welche Art von Vorschlägen übernommen werden darf und wo eine manuelle Prüfung nötig ist.
  • Vertragliche Zusicherungen: Bei zugekaufter Software lohnt die Frage, welche Gewährleistung der Anbieter zur Rechtekette gibt.

Autonomie realistisch beschreiben

  • Trennen zwischen Demo und Regelbetrieb: Was in einer kontrollierten Vorführung funktioniert, ist noch kein belastbarer Prozess. Sinnvoll ist eine Pilotphase mit echten Fällen und gemessener Fehlerquote.
  • Den menschlichen Anteil benennen: Ein Human-in-the-Loop – also ein Mensch, der Zwischenergebnisse prüft oder freigibt – ist kein Makel, sondern oft die einzige vertretbare Bauweise. Er gehört aber in die Prozessdokumentation und, wo Dritte betroffen sind, in die Kommunikation.
  • Datenschutz mitdenken: Wenn Menschen Inhalte sehen oder Gespräche führen, die Nutzerinnen und Nutzer für maschinell verarbeitet halten, ändert das die datenschutzrechtliche Bewertung.

Der Hype als Taktgeber

Dass OpenAI bereits eine eigene Antwort auf Muse diskutiert, zeigt die Dynamik im Feld. Solche Wettläufe erzeugen Druck, Funktionen früh anzukündigen und die Lücke zwischen Ankündigung und Umsetzung hinter dem Produktnamen zu verbergen. Für Unternehmen, die derartige Dienste einkaufen oder integrieren wollen, ist das ein Argument für Nüchternheit: Nicht die Ankündigung ist die Grundlage der Planung, sondern das, was sich in einem eigenen Test reproduzieren lässt.

Hilfreich sind dabei wenige, aber klare Fragen an Anbieter: Welche Schritte laufen vollständig automatisiert? Wo greifen Menschen ein? Welche Daten verlassen dabei das System? Und wie ist die Rechtekette am Code dokumentiert? Antworten, die ausweichend bleiben, sind selbst eine Information.

Einordnung

Für Web- und Softwareprojekte bedeutet der Fall Muse vor allem zweierlei. Erstens gehört die Prüfung von Lizenzen und Codeherkunft in den Standardablauf, sobald KI-Werkzeuge an der Entstehung beteiligt sind – nachträglich ist das deutlich aufwendiger. Zweitens sollten Agentenfunktionen im Angebot so beschrieben werden, wie sie im Betrieb tatsächlich laufen, inklusive der Stellen, an denen Menschen prüfen oder eingreifen. Das schützt vor Enttäuschungen im Projekt und vor Diskussionen, die später niemand führen möchte.

Quellen