Der Clowdr KI-Standard: Was als auslieferbare Arbeit zählt

KI-Debatten kippen schnell in Reinheitstests. Für ein Game-Projekt ist das nutzlos.

Clowdr braucht einen Standard, den Entwickler:innen, Künstler:innen, Komponist:innen, Designer:innen, Autor:innen und Projektleitungen anwenden können, bevor KI-gestützte Arbeit Teil eines Spiels wird, das ausgeliefert werden soll. Kein Bauchgefühl. Kein Debattenprompt. Eine Messlatte.

Das ist diese Messlatte für Code, Visual Art, Audio, Design und Narrative. Sie erklärt, wer die Arbeit verantwortet, welche Verifikation zählt, was durchfällt, was offengelegt werden muss und was passiert, wenn Mitwirkende widersprechen.

Der Standard in einem Satz

Kein generiertes Ergebnis wird ausgeliefert, ohne dass ein Mensch die Verantwortung übernimmt und einen angemessenen Verifikationsdurchgang macht.

"KI ist okay, ship einfach alles, was rauskommt" verfehlt den Punkt. "KI hat es berührt, also ist die Arbeit vergiftet" verfehlt ihn auch. Die härtere Frage ist, ob eine menschliche mitwirkende Person diese Arbeit gut genug verantwortet, um sie ins Spiel zu bringen.

Bei Clowdr beginnt generiertes Material als Entwurf: ein von einem Agenten geschriebener Patch, ein generiertes Prop-Sheet, ein Temp-Cue, eine Mechanikliste oder ein Dialog-Pass.

Entwürfe können einen Prototyp entblocken, ein Gespräch konkret machen oder eine Richtung sichtbar machen, die das Team ablehnen sollte, bevor jemand eine Woche damit verbringt, sie zu polieren.

Entwurf ist nicht Lieferung.

Lieferung beginnt, wenn eine mitwirkende Person sagen kann: Ich weiß, warum das hier hingehört, woher es kommt, was ich geändert habe, wie es geprüft wurde und warum ich die Verantwortung dafür übernehme.

Das gilt für KI-gestützte und handgemachte Arbeit. Ein handgemaltes Sprite mit unklaren Rechten und ohne Lesbarkeitscheck im Build scheitert genauso wie ein generiertes Sprite. Ein handgeschriebenes System, das niemand warten kann, scheitert genauso wie agentengeschriebener Code.

Menschliche Verantwortung ist kein Vibe

Menschliche Verantwortung bedeutet, dass eine namentlich bekannte mitwirkende Person die finale Arbeit verantwortet.

Nicht der Prompt. Nicht das Modell. Nicht "der Agent hat das geschrieben." Nicht "der Generator hat das gemacht." Eine Person verantwortet die Entscheidung, das Ergebnis zu verwenden, die Änderungen nach der Generierung, die eingeführten Risiken und die Verifikation.

Für Clowdr-Arbeit hat Verantwortung drei Teile: Entscheidung, Source und Handoff.

Verantworte die Entscheidung

Die mitwirkende Person muss erklären können, warum die Arbeit in dieses Projekt gehört.

Für Code heißt das: Architektur und Edge Cases erklären. Für Art heißt das: Stil-Fit, Lesbarkeit, Polish und Rechte erklären. Für Audio heißt das: emotionale Absicht, Timing, Mix, Implementierung und Lizenzstatus erklären. Für Design und Narrative heißt das: Spielerabsicht, Kohärenz, Constraints und Änderungen nach dem Testen erklären.

Wenn die Antwort "sah gut aus" oder "das Modell hat es mir gegeben" lautet, ist die Arbeit noch nicht verantwortet.

Verantworte die Source

Generierte Arbeit braucht Source-Notizen.

Nicht jedes Experiment braucht ein juristisches Memo. Alles, was für Projektnutzung vorgeschlagen wird, braucht genug Dokumentation, damit eine andere mitwirkende Person die Entscheidung später prüfen kann.

Mindestens brauchst du Tool-Name, Datum, mitwirkende Person, Einsatzzweck, Lizenz- oder Terms-Notiz und den Status des Outputs: Konzept, Temp, intern oder vorgeschlagenes finales Material. Wenn die Terms unklar sind, wandert die Arbeit nicht ohne Review in den finalen Stand.

Das ist wichtig, weil Plattformen schon danach fragen. Die Steam Content Survey hat inzwischen einen Abschnitt zu generativer KI für vorab generierte und live generierte KI-Inhalte. Sie fragt Entwickler:innen, wie KI in der Entwicklung oder im Produkt verwendet wurde. Steam sagt außerdem, dass vorab generierte KI-Inhalte wie andere Inhalte geprüft werden. Siehe die Steamworks Content Survey.

Urheberrecht entsteht nicht, weil ein Prompt clever war. Der Copyrightability Report 2025 des U.S. Copyright Office sagt, dass Prompts allein nach aktuell allgemein verfügbarer Technologie nicht genug menschliche Kontrolle liefern, um die Nutzer:in zur Autor:in des Outputs zu machen. Siehe den Copyright Office Part 2 Report.

Die praktische Regel ist einfach: Wenn niemand Source und Rechte-Status erklären kann, sollte niemand die Arbeit promoten.

Verantworte den Handoff

KI-gestützte Arbeit muss trotzdem durch ein Team wandern.

Die nächste mitwirkende Person sollte keine Mystery Box erben. Ein Handoff sollte sagen, was das Material ist, was ein Mensch geändert hat, was noch Review braucht und wer signiert.

Ein generiertes Image Board, das einer Künstlerin mit "mach das final" übergeben wird, ist kein Handoff. Ein generierter Combat-Prototyp, der einem anderen Entwickler ohne Edge-Case-Notizen übergeben wird, ist kein Handoff. Ein Temp Music Cue, der einer Komponistin mit unklaren Rechten und ohne Erlaubnis zum Ersetzen übergeben wird, ist kein Handoff.

Was Verifikation für Code bedeutet

Code-Verifikation ist nicht nur Unit-Tests.

Spiele sind keine SaaS-Dashboards. Manchmal ist der richtige Check ein Unit-Test. Manchmal ein sauberer Build, ein Smoke-Test, ein Profiler-Lauf oder ein Playtest, weil der Bug erst auftaucht, wenn ein Mensch während eines Übergangs das Menü öffnet, stirbt, neu lädt und es noch einmal versucht.

Die Entwickler:in schlägt einen Verifikationsdurchgang vor, der zum Risiko passt. Reviewer können mehr verlangen, bevor die Änderung shipped.

Eine KI-gestützte Code-Änderung erfüllt den Standard, wenn eine Entwickler:in die Änderung erklären, sie in die Architektur einordnen, die Fehlermodi benennen und zeigen kann, dass die Verifikation zum Risiko passte.

Beispiel, das den Standard erfüllt: Ein Agent entwirft eine Save-Migration für ein neues Inventarschema. Die Entwickler:in prüft die Datenform, entfernt unnötige Abstraktionen, schreibt einen Migrationstest für alte Saves, lässt den Build laufen, smoke-testet Laden und Neuladen, prüft den Editor-Workflow und dokumentiert die Änderung.

Beispiel, das scheitert: Ein Agent refactort doppelten Inventarcode in eine sauberere Abstraktion. Es kompiliert. Aber die Autorin kann den neuen Dependency-Pfad nicht erklären, das Editor-Tooling verliert Item-Previews, alte Saves sind ungetestet und niemand prüft die Steam-Deck-Auflösung nach der UI-Änderung. Das ist kein Refactoring. Das ist Haftung mit schöneren Dateinamen.

Was Verifikation für Visual Art bedeutet

Visual-Art-Verifikation passiert im Spielkontext, nicht in einer isolierten Bildvorschau.

Ein generiertes Bild kann Referenz, Moodboard, Prop-Richtung, Farbtest, Placeholder oder wegwerfbare Exploration sein. Auslieferbar wird es erst, wenn eine Künstler:in die finale Richtung verantwortet und das Asset in der visuellen Sprache des Projekts funktioniert.

Beispiel, das den Standard erfüllt: Eine Projektleitung generiert zehn Prop-Varianten für einen Potion Shop. Die Künstlerin nutzt sie als Referenz, zeichnet die finalen Props im Stil des Projekts neu, vereinfacht Silhouetten für Gameplay-Größe, prüft die Palette gegen das Biome, testet Kompression, bestätigt den Lizenzpfad und ergänzt die finalen Assets im Style Bible.

Beispiel, das scheitert: Ein generiertes Character Concept sieht teuer aus, also promotet das Team es zu finaler Art. Es gibt keinen Turnaround, keinen Animationsplan, keine Materialkonsistenz, keine Silhouette auf Gameplay-Größe, keine Source-Notiz und keine Rechteklarheit. Das ist keine finale Art. Das ist ein JPEG mit Schulden dran.

Künstler:innen sind nicht da, um Output abzunicken. Sie verantworten Kohärenz, Polish, Lesbarkeit, Optimierung und Rechte. Wenn diese Verantwortung fehlt, bleibt das Asset Entwurf.

Was Verifikation für Audio bedeutet

Audio-Verifikation passiert im Build, gegen Gameplay-Timing, Dialog, Effekte, Übergänge, Loops und Spieleraufmerksamkeit.

Ein Track kann im Browser-Tab gut klingen und trotzdem in einem Spiel scheitern. Er kann schlecht loopen, Dialog bekämpfen, wichtige Effekte überdecken, die Szene verfehlen oder Implementierungsschulden erzeugen, weil es keine Stems, keinen Tail, keinen Übergangsplan oder keine Lizenzklarheit gibt.

Generiertes Audio ist Entwurfsmaterial, bis eine Komponist:in oder Audio-Mitwirkende:r emotionale Absicht, Timing, Mix, Implementierung und Rechte verantwortet.

Beispiel, das den Standard erfüllt: Eine Designerin nutzt ein KI-Tool, um einen Temp-Cue mit kurzem Motiv für einen Waldboss zu erstellen. Die Komponistin behandelt ihn als Mood-Referenz, schreibt einen neuen Cue, trennt Stems für Combat-Intensität, mischt gegen Dialog und Hit Sounds, testet den Loop, prüft Übergangstiming, dokumentiert Rechte und implementiert den Cue im Build.

Beispiel, das scheitert: Ein generierter Boss-Track klingt isoliert riesig, also legt das Team ihn ins Spiel. Er loopt nach neunzig Sekunden mit einer offensichtlichen Naht, lässt sich nicht für Phasenwechsel in Stems teilen, verschmiert Combat-Lesbarkeit und niemand kann die Lizenz erklären. Das ist keine billige Musik. Das ist Risiko mit Reverb.

Was Verifikation für Design und Narrative bedeutet

Design- und Narrative-KI scheitern, wenn sie abstrakt bleiben.

Ein Modell kann Mechaniken, Quests, Enemy-Ideen, Economy Loops, Dialog-Passes, Item-Beschreibungen, Lore-Fragmente und verzweigte Entscheidungen generieren. Nichts davon verdient einen Platz, bis eine Designer:in oder Autor:in daraus eine kohärente Spielerfahrung macht.

Für Design bedeutet Verifikation Kontakt mit Spieler:innen oder mit dem spielbaren Build.

Beispiel, das den Standard erfüllt: KI generiert zwanzig Ideen für Movement-Upgrades. Die Designerin wählt drei Hypothesen, schneidet den Rest, prototypet eine, beobachtet, wie Spieler:innen sie ausnutzen, passt Constraints an und entscheidet, ob sie den Core Loop stärkt.

Beispiel, das scheitert: Eine generierte Mechanik klingt in einem Pitch-Dokument clever, also baut das Team zwei Wochen um sie herum. Im Playtest bringt sie Spieler:innen dazu, dem besten Teil des Combat auszuweichen. Eine Mechanik, die nur im Kopf der Designerin funktioniert, ist noch keine Mechanik.

Für Narrative bedeutet Verifikation Voice, State, Kontinuität und Spieler-Kontext.

Beispiel, das den Standard erfüllt: KI entwirft alternative Bark Lines für einen Merchant. Die Autorin schreibt sie für Character Voice um, entfernt Lore-Widersprüche, prüft Quest-State-Varianten, testet Timing in der Szene und markiert, welche Lines final sind. Das Tool half, Rohmaterial zu erzeugen. Die Autorin hat die Szene geschrieben.

Beispiel, das scheitert: Generierter Quest-Text widerspricht dem, was in der vorherigen Mission passiert ist, setzt nach einem Character Death die falsche emotionale Temperatur und verweist auf ein Item, das die Spielerin vielleicht nie gefunden hat. Isoliert liest es sich okay. Im Spiel bricht es.

Design wird schwach, wenn es zu abstrakt wird. Clowdrs Regel ist, es zurück ins Spiel zu holen. Drück Play. Beobachte die Spielerin. Prüfe die Szene. Dann entscheide.

Was den Standard nicht erfüllt

Arbeit erfüllt den Standard nicht, wenn keine namentlich bekannte Person sie verantwortet.

Sie erfüllt den Standard nicht, wenn Source oder Lizenz unklar sind.

Sie erfüllt den Standard nicht, wenn die mitwirkende Person nicht erklären kann, was sich nach der Generierung geändert hat.

Sie erfüllt den Standard nicht, wenn das Material nur isoliert gut aussieht.

Sie erfüllt den Standard nicht, wenn niemand sie im tatsächlichen Kontext getestet hat, in dem Spieler:innen ihr begegnen werden.

Sie erfüllt den Standard nicht, wenn die nächste mitwirkende Person einen Haufen Output ohne Handoff-Notizen bekommt.

Sie erfüllt den Standard nicht, wenn eine Projektleitung sie akzeptiert, weil das Team müde ist.

Der letzte Punkt ist wichtig. Viel schlechte KI-Nutzung ist Erschöpfung. Das Projekt ist spät dran, die Künstlerin ist überlastet, die Komponistin wurde zu spät eingebunden, die Entwickler:in räumt drei Systeme auf und das generierte Ding sieht gut genug aus, um den Schmerz zu stoppen.

Genau dann muss der Standard halten.

Slop heißt nicht "KI war beteiligt." Slop ist Arbeit ohne Verantwortung und Verifikation. Derselbe Standard fängt auch schlechte handgemachte Arbeit ab.

Rechte, Offenlegung und Receipts

KI-gestützte Arbeit braucht Receipts, bevor sie shipped.

Receipts müssen die Fragen beantworten, die Projektleitung, Mitwirkende, Plattform-Reviewer oder zukünftige Teammates später stellen werden.

Für jeden KI-gestützten Beitrag, der für finalen Einsatz vorgeschlagen wird, dokumentiere:

1. Die menschliche Owner-Person.
2. Das verwendete Tool oder die verwendete Source.
3. Datum und Einsatzzweck.
4. Ob das Material Konzept, temporär, intern oder vorgeschlagen final ist.
5. Was der Mensch nach der Generierung geändert hat.
6. Die Rechte- oder Lizenznotiz.
7. Den Verifikationsdurchgang.
8. Jede nötige Offenlegung für Plattform, Storefront, Credits oder Contributor Agreement.

Steams KI-Survey ist ein Grund, warum das nicht informell bleiben kann. Wenn ein Spiel KI-Services während der Entwicklung genutzt hat oder sie im Produkt enthält, muss die Entwickler:in diese Implementierung vielleicht beschreiben. Storefront-Offenlegung kann für Spieler:innen sichtbar werden.

Urheberrecht ist ein weiterer Grund. Menschliche Autorenschaft zählt. Wenn eine mitwirkende Person nur Prompts geschrieben und ein Ergebnis ausgewählt hat, entsteht dadurch vielleicht nicht die Rechteposition, die das Projekt braucht. Wenn ein Mensch editiert, arrangiert, integriert und ein größeres Werk autorisiert, ändert sich die Analyse. Deshalb sollte der Receipt sagen, was der Mensch getan hat.

Das Ziel ist nicht Papierkram um seiner selbst willen. Das Ziel ist, dass Mitwirkende das Rechteproblem nicht erst entdecken, wenn das Asset schon im Trailer steckt.

Wenn Mitwirkende widersprechen

Widerspruch ist normal.

Eine Künstlerin kann eine generierte visuelle Richtung ablehnen, die ein Entwickler für gut genug hält. Eine Komponistin kann sich weigern, einen generierten Track mit unklaren Rechten aufzuräumen. Eine Entwickler:in kann einen Agenten-Patch blocken, weil die Autorin die Architektur nicht erklären kann. Eine Autorin kann generierten Dialog ablehnen, weil er Character Voice bricht.

Bei Clowdr sollte dieser Widerspruch nicht zu einem Referendum darüber werden, ob KI gut oder schlecht ist. Es ist eine Produktionsentscheidung.

Nutze diesen Prozess:

1. Pausiere die Promotion der Arbeit.
2. Identifiziere Domain Owner oder Reviewer: Künstler:in, Komponist:in oder Audio-Mitwirkende:r, Entwickler:in, Designer:in, Autor:in, Projektleitung oder Editorial Owner.
3. Prüfe die Receipts: Source, Rechte, Änderungen, Einsatzzweck und Verifikation.
4. Teste die Arbeit im Kontext.
5. Entscheide, ob sie den Standard erfüllt, Revision braucht, temporär bleibt oder geschnitten wird.
6. Dokumentiere die Entscheidung, damit dieselbe Diskussion nächste Woche nicht neu startet.

Wenn es um Rechte, Offenlegung oder Plattform-Compliance geht, gewinnt die konservative Antwort, bis das Risiko gelöst ist.

Wenn es um Taste oder Fit geht, hat der Domain Owner ernsthaftes Gewicht. Entwickler:innen erklären Künstler:innen nicht Art zurück. Projektleitungen behandeln Audio nicht als Deko, nur weil der Track schon existiert. Autor:innen werden nicht von einem generierten Absatz überstimmt, der poliert klingt, aber die Szene bricht.

Die Projektleitung muss trotzdem Entscheidungen treffen. Das gehört zum Shippen. Aber die Entscheidung sollte dem Standard antworten, nicht der Person, die im Chat am müdesten ist.

Die Contributor-Checkliste

Bevor KI-gestützte Arbeit vom Entwurf zum finalen Stand wandert, beantworte diese Fragen:

1. Wer ist die menschliche Owner-Person?
2. Was wurde generiert, und mit welchem Tool oder welcher Source?
3. Wofür ist das Material gedacht: Konzept, Temp, intern oder final?
4. Was hat ein Mensch nach der Generierung geändert?
5. Welche Rechte-, Lizenz- oder Source-Notiz hängt daran?
6. Zu welcher Domain gehört das: Code, Visual Art, Audio, Design, Narrative oder gemischt?
7. Welcher Verifikationsdurchgang passt zum Risiko?
8. Wurde die Arbeit im Kontext geprüft, nicht nur isoliert?
9. Wer hat aus der relevanten Domain signiert?
10. Braucht irgendetwas Offenlegung auf Steam, in einem anderen Storefront, in Credits, Contributor Agreements oder Projektnotizen?
11. Kann die nächste mitwirkende Person den Handoff verstehen, ohne zu raten?

Wenn die Checkliste für ein winziges internes Experiment zu schwer wirkt, halte das Experiment intern. Nutze sie, wenn die Arbeit für Projektnutzung vorgeschlagen wird.

Die Linie ist nicht kompliziert. Sie wird nur leicht übersprungen, wenn eine Abkürzung wie Fortschritt aussieht.

Was du als Nächstes tun kannst

Dieser Standard sitzt unter How We Ship, dem Clowdr-Manifest für Tools, Taste, Verantwortung, Rechte und ausgelieferte Qualität.

Die Vertiefungen gehen je Disziplin weiter: Geschmack ist immer noch der Job für Artists, Sound ist mehr als Generierung für Komponist:innen und Audio-Mitwirkende und Das Werkzeug ist nicht der Architekt für Entwickler:innen.

Die gemeinsame Regel ist in jedem Fall dieselbe.

Nutze die Tools, die helfen. Verantworte die Arbeit. Verifiziere sie im Kontext. Halte Rechte sauber. Respektiere die Mitwirkenden um dich herum. Shippe etwas, das standhält.

Wenn das nach dem Standard klingt, unter dem du arbeiten willst, melde dich an.