Mein System für die Arbeit mit KI

Meine KI-Arbeit passt nicht in einen Prompt.

Offizielle Produktquelle: OpenAI: Projects in ChatGPT

Sie passt nicht einmal in einen Chat.

Ein guter Prompt kann eine Aufgabe hervorragend auslösen. Er sagt einem System, was es jetzt tun soll. Was er normalerweise nicht regelt: Welche Quelle verbindlich ist, welche Rolle entscheiden darf, was gestern vereinbart wurde, wie ein Fehler dokumentiert wird und woran ein anderes System morgen erkennt, wo es weitergehen muss.

Genau deshalb habe ich mir über die vergangenen Jahre ein KI-Betriebssystem aufgebaut.

Damit meine ich keine neue App und kein geheimes technisches Produkt. Ich meine die Struktur hinter meiner Arbeit: Projekte, Rollen, Kontext, Workflows, Standardabläufe, Vorlagen, Qualitätsprüfungen, Versionen und ein Archiv.

Ein Prompt erzeugt eine Antwort. Ein KI-Betriebssystem erzeugt Anschlussfähigkeit.

Es sorgt dafür, dass nicht jeder Auftrag wieder mit einer leeren Chatbox und der Hoffnung beginnt, die Maschine werde schon erraten, was diesmal gemeint ist.

Buch · Die Journalisten-Methode

Vom Rohmaterial zum eigenständigen Beitrag.

Wenn du mit KI arbeitest, aber nicht wie alle anderen klingen willst, zeigt dir die Journalisten-Methode einen belastbaren Weg: eigene Quellen, bessere Fragen und menschliche Endabnahme.

Buch bei Amazon ansehen → Methode zuerst kennenlernen

Der Amazon-Link ist ein Affiliate-Link. Für dich ändert sich der Preis nicht.

Vom Zauberspruch zum Betrieb

Als generative KI für viele Menschen zugänglich wurde, drehte sich fast alles um Prompting.

Welcher Satz funktioniert? Welche Rolle soll man zuweisen? Welche Formulierung macht den Output angeblich zehnmal besser? Prompt-Sammlungen wurden gehandelt wie magische Schriftrollen.

Das war für den Einstieg nicht völlig unsinnig. Ein präziser Auftrag ist weiterhin wichtig. Das Problem beginnt dort, wo man den Prompt für das ganze System hält.

Ein Unternehmen kann einen ausgezeichneten Prompt für einen Fachartikel besitzen und trotzdem in jedem Durchlauf dieselben Fehler produzieren:

• Das Briefing ist unvollständig.
• Die falsche Datei wird verwendet.
• Die Zielgruppe wechselt unterwegs.
• Zitate haben keinen nachvollziehbaren Ursprung.
• Niemand weiß, wer Fakten freigibt.
• Metadaten und interne Links werden vergessen.
• Der fertige Text verschwindet in einem Chat.
• Drei Wochen später beginnt alles wieder von vorn.

Der Prompt war dann nicht schlecht. Er war nur hoffnungslos überfordert.

Ich unterscheide deshalb drei Ebenen:

1. Auftrag: Was soll in diesem Moment geschehen?
2. Workflow: Wie wird aus Material ein geprüftes Ergebnis?
3. Betriebssystem: Welche Regeln, Rollen, Wissensspeicher und Übergaben tragen viele Workflows über längere Zeit?

Mein Beitrag über Kontext-Engineering erklärt, was ein System für eine konkrete Aufgabe wissen muss. Die KI-Strategie für Content-Teams klärt, warum und unter welchen Risiken ein Anwendungsfall überhaupt gebaut wird.

Hier geht es um die Ebene dazwischen und darunter: die konkrete Wissens- und Prozessarchitektur, an die Projekte immer wieder andocken.

Was ich unter einem KI-Betriebssystem verstehe

Ein Betriebssystem koordiniert Ressourcen, Zustände und Zugriffe. Diese technische Analogie lässt sich nicht eins zu eins auf Wissensarbeit übertragen. Sie trifft aber einen wichtigen Punkt.

Mein KI-Betriebssystem beantwortet sieben wiederkehrende Fragen:

1. Welche Grundregeln gelten immer?
2. Welche Projekte existieren und wofür?
3. Welche Informationen sind verbindlich?
4. Welche Rollen übernehmen Mensch und KI?
5. Wie läuft eine wiederkehrende Aufgabe ab?
6. Wie werden Entscheidungen und Fehler dokumentiert?
7. Wie bleibt das System aktuell, prüfbar und übergabefähig?

Die Antworten liegen nicht nur in meinem Kopf. Sie werden so dokumentiert, dass ich nach einer Pause weiterarbeiten kann und ein anderes zugelassenes System den Stand versteht.

Der eigentliche Hebel liegt nicht in maximaler Automatisierung, sondern darin, Grundlagenarbeit nicht zum zweiten, dritten und siebten Mal zu wiederholen.

Ebene 1: Grundprinzipien und Entscheidungsrechte

Ganz oben stehen die Regeln, die nicht bei jeder Aufgabe neu verhandelt werden sollen.

Dazu gehören bei mir beispielsweise:

• KI ist Werkzeug und Sparringspartner, nicht rechtlicher oder moralischer Verantwortungsträger.
• Persönliche Erfahrungen, Kunden, Zahlen und Zitate werden nicht erfunden.
• Sensible Daten kommen nur in ausdrücklich freigegebene Systeme und werden soweit möglich minimiert oder geschwärzt.
• Die stärkste Quelle ist nicht die letzte KI-Antwort, sondern der überprüfbare Ursprung.
• Veröffentlichung braucht eine benannte menschliche Freigabe.
• Schwer reversible Änderungen benötigen Sicherung, begrenzten Umfang und eine Stop-Regel.
• Systeme dürfen Unsicherheit nicht in Gewissheit verwandeln.

Hinzu kommen Entscheidungsrechte:

• Wer darf einen Prozess starten?
• Wer darf Material freigeben?
• Wer entscheidet bei widersprüchlichen Quellen?
• Wer darf eine Website ändern?
• Wer darf veröffentlichen?
• Welche Arbeit bleibt grundsätzlich menschlich?

„Human in the Loop“ ist mir dafür zu weich. Ein Mensch kann auch dekorativ in einer Schleife sitzen und alles abnicken.

Ich möchte wissen, ob dieser Mensch Einblick, Kompetenz und ein echtes Vetorecht besitzt.

Ebene 2: Getrennte Projekte statt eines endlosen Universal-Chats

Ein Projekt ist ein abgegrenzter Arbeitsraum für einen wiederkehrenden Zweck.

Ich habe beispielsweise getrennte Projekte für:

• saschategtmeyer.com;
• Just Wanderlust;
• Schreiben und Redaktion;
• Akquise;
• digitale Produkte;
• Fitness;
• Italienisch;
• vorbereitende Buchhaltung;
• meinen persönlichen Assistenten.

Diese Trennung ist keine Bürokratie. Ein Fitnesscoach braucht andere Quellen, Regeln und Risikogrenzen als ein WordPress-Operator. Ein Schreibprojekt muss meine Voice-DNA kennen. Ein Buchhaltungsprojekt darf nicht dieselben Freiheiten besitzen wie eine Ideensammlung.

Aktuelle KI-Plattformen bieten dafür unterschiedliche Projektmechaniken. ChatGPT Projects bündeln Chats, Dateien und Anweisungen unter einem gemeinsamen Ziel. Claude Projects arbeiten mit eigenen Wissensbasen und Projektkontext. Gemini Gems lassen sich mit eigenen Anweisungen für wiederkehrende Aufgaben konfigurieren.

Diese Funktionen sind nicht identisch und ändern sich. Ich behandle sie deshalb nicht als mein Betriebssystem selbst. Sie sind Laufzeitumgebungen dafür.

Das System muss notfalls umziehen können.

Ebene 3: Kontext mit Hierarchie statt Dateihaufen

Kontext ist nicht einfach „alles hochladen“.

Ein Projekt braucht eine Hierarchie, sonst entsteht ein Kontextfriedhof: viele Dateien, mehrere Fassungen, widersprüchliche Regeln und keine klare Antwort darauf, was gilt.

Ich unterscheide mindestens:

Verbindlich

Aktuelles Briefing, freigegebene Regeln, gültige Quellen, Markenentscheidungen und die neueste Version eines Dokuments.

Referenz

Beispiele, Hintergrundmaterial, frühere gute Arbeiten und methodische Dossiers.

Rohmaterial

Diktate, Interviews, Notizen, Screenshots, Datenexporte und unfertige Gedanken.

Historisch

Alte Versionen und Entscheidungen, die für die Entwicklung nachvollziehbar bleiben sollen, aber nicht mehr gelten.

Datenlücke

Informationen, die fehlen, strittig oder noch zu prüfen sind.

Gerade die letzte Kategorie verhindert erstaunlich viel Unsinn. Eine Lücke ist kein Auftrag, sie mit plausibler Sprache zu tapezieren.

Für lebenden Arbeitskontext nutze ich gern einfache Text- und Markdown-Dateien, nicht weil Markdown magisch wäre, sondern weil sich Inhalte, Überschriften, Links und Versionen darin leicht erkennen, vergleichen und zwischen Werkzeugen übertragen lassen.

PDFs bleiben wichtig für veröffentlichte Dokumente oder Layout. Für Regeln, Vorlagen und häufig veränderte Arbeitsstände sind einfache Formate oft weniger widerspenstig.

Content · Redaktion · KI-Workflows

Wenn aus einer guten Idee ein verlässlicher Prozess werden soll.

Ich unterstütze stille Experten und kleine Teams dabei, Fachwissen in klare Inhalte, belastbare Redaktionsabläufe und sinnvolle KI-Workflows zu übersetzen.

Projekt kurz schildern → Leistungen ansehen

Ein paar klare Sätze reichen. Keine automatisierte Verkaufsschleife.

Ebene 4: Rollen – der Stabschef ist nicht der Schreiber

In meinem System gibt es einen zentralen persönlichen Assistenten, den ich als digitalen Stabschef bezeichne. Er priorisiert, hält Kontext, erstellt Briefings und routet Aufgaben.

Daneben existieren spezialisierte Rollen, etwa für:

• Recherche;
• Schreiben;
• Quellen- und Faktenprüfung;
• SEO;
• Social-Media-Aufbereitung;
• technische Website-Arbeit;
• Dokumenten- und Verwaltungsaufgaben.

Die Rollen verhindern zwei typische Fehler.

Erstens muss nicht jedes System alles wissen. Ein SEO-Projekt braucht keine privaten Tagebucheinträge. Ein persönlicher Assistent braucht keine vollständigen Rechnungsarchive.

Zweitens wird sichtbar, welche Art von Urteil gerade gefragt ist. Eine Instanz, die einen Entwurf schreibt, sollte nicht automatisch ihre eigene Arbeit freigeben. Ein zweites System kann angreifen. Die Veröffentlichung bleibt trotzdem eine menschliche Entscheidung.

Der Stabschef ist also nicht der beste Spezialist für jede Aufgabe. Er ist der Knotenpunkt.

Wie im echten Betrieb wäre ein Chef, der jede Aufgabe selbst an sich zieht, kein Zeichen besonderer Stärke. Eher ein Engpass mit Kalenderzugriff.

Ebene 5: Workflows und SOPs

Ein Workflow beschreibt die Abfolge. Eine SOP – eine Standard Operating Procedure – beschreibt, wie ein wiederkehrender Schritt konkret ausgeführt und geprüft wird.

Für einen Fachbeitrag kann der Workflow so aussehen:

1. Seitenjob und Leserfrage klären.
2. Primärmaterial erzeugen oder einsammeln.
3. Transkript und Dokumente auswerten.
4. Recherche- und Quellenlücken schließen.
5. Ein Verzeichnis prüfbarer Behauptungen (Claim Ledger) aufbauen.
6. Struktur und vollständigen Entwurf entwickeln.
7. Fakten, Logik, Fairness und Voice getrennt prüfen.
8. Bilder, interne Links und Metadaten vorbereiten.
9. Als WordPress-Entwurf einpflegen.
10. Mobilansicht, Canonical-URL, Links und Freigabe kontrollieren.
11. Erst nach menschlicher Zustimmung veröffentlichen.

Eine SOP für die Quellenprüfung könnte zusätzlich festlegen:

• Primärquellen vor Sekundärquellen;
• aktuelle Produktangaben am Veröffentlichungstag prüfen;
• persönliche Aussagen gegen Rohmaterial kontrollieren;
• Unsicherheit markieren;
• keine Quelle aus einer früheren KI-Antwort übernehmen, wenn der Ursprung fehlt.

Damit wird die Qualität nicht automatisch perfekt. Sie wird prüfbar.

Ebene 6: Vorlagen, die Entscheidungen beschleunigen

Vorlagen sind dort sinnvoll, wo dieselben Fragen wiederkommen.

Zu meinem System gehören unter anderem:

• Projektstart-Briefing;
• Kontextpaket;
• Interviewleitfaden;
• Claim Ledger;
• Quellenlog;
• Realitätsfilter;
• Redaktions- und Qualitätschecklisten;
• WordPress-Einpflegeprompt;
• Tagesrückblick;
• Abschluss- und Übergabebericht.

Eine gute Vorlage nimmt Denken nicht weg. Sie erinnert an Entscheidungen, die unter Zeitdruck gern verschwinden.

Eine schlechte Vorlage produziert dagegen ritualisierte Vollständigkeit. Dann werden zwanzig Felder ausgefüllt, obwohl niemand weiß, wofür.

Meine Regel lautet:

Eine Vorlage darf Reibung reduzieren. Sie darf nicht den Eindruck erzeugen, eine Entscheidung sei getroffen, nur weil ein Feld Text enthält.

Ebene 7: Tagesrückblicke, Versionierung und Archiv

Ein System lebt nicht nur von dem, was aktuell sichtbar ist. Es lebt von seinem Zustand.

Deshalb dokumentiere ich:

• getroffene Entscheidungen;
• offene Fragen;
• Fehler und ihre Ursache;
• geänderte Regeln;
• verwendete Versionen;
• nächste Schritte;
• verworfene Ansätze.

Die KI kann diese Dokumentation zu einem großen Teil vorbereiten. Sie kennt den Gesprächsverlauf, kann Aufgaben extrahieren und Änderungen zusammenfassen.

So entsteht Dokumentation von der KI für die KI.

Ein späteres System liest den Projektstand und steigt ein, statt dieselbe Geschichte zum achten Mal erzählt zu bekommen. Ich muss den Rückblick nicht jeden Abend als literarisches Werk genießen. Er muss anschlussfähig sein.

Wichtige Dokumente werden versioniert. Eine neue Fassung ersetzt die alte nicht unsichtbar. Das ist besonders bei Regeln, Prompts und Qualitätsfiltern entscheidend. Ein besseres Modell kann später einen alten Entwurf prüfen. Dafür muss er noch existieren.

Was nicht mehr aktiv gebraucht wird, wandert ins Archiv statt reflexhaft in den Papierkorb.

Ein Archiv ist kein Müllplatz. Es ist Geschichte mit Status.

So sieht die Architektur in einer einfachen Ordnerstruktur aus

Die technische Umsetzung darf unspektakulär sein. Eine mögliche Struktur lautet:

00_OPERATING_SYSTEM/
  Grundprinzipien.md
  Rollen-und-Entscheidungsrechte.md
  Daten-und-Sicherheitsregeln.md

01_PROJEKTE/
  Website-Sascha/
  Just-Wanderlust/
  Schreibsystem/
  Akquise/

02_WORKFLOWS_SOPS/
  Fachbeitrag-von-Diktat-bis-WordPress.md
  Content-Update.md
  Quellenpruefung.md

03_REFERENZEN/
  Voice-DNA.md
  Quellenarchitektur.md
  Gute-Beispiele/
  Schlechte-Beispiele/

04_TEMPLATES/
  Projektbriefing.md
  Claim-Ledger.md
  Tagesrueckblick.md

05_LOGS_VERSIONEN/
  Changelog.md
  Entscheidungen/
  Tagesrueckblicke/

99_ARCHIV/

Das ist kein universeller Standard. Es zeigt nur die Logik:

• Grundregeln getrennt von Projekten;
• Projekte getrennt von wiederverwendbaren Methoden;
• Referenzen getrennt von verbindlichen Anweisungen;
• Versionen und Historie sichtbar;
• Archiv statt unkontrollierter Vermischung.

Ein Solo-Selbstständiger kann das in einem schlichten Ordner abbilden. Ein Team braucht zusätzlich Zugriffsrechte, Eigentümer, Freigaben und eine saubere technische Umgebung.

Sechs typische Fehler beim Aufbau

1. Der Prompt-Friedhof

Hunderte Prompts werden gesammelt, aber niemand weiß, welcher noch gilt, welchen Zweck er erfüllt und mit welchem Material er getestet wurde.

2. Der Kontextfriedhof

Alles landet in einem Projekt, weil mehr Kontext bessere Ergebnisse erzeugen soll. Tatsächlich konkurrieren dann alte und neue Anweisungen miteinander.

3. Die Modellfixierung

Der gesamte Prozess hängt an einer bestimmten Version oder einem Anbieter. Beim nächsten Update beginnt der Umbau von vorn.

4. Fehlende Verantwortlichkeit

Die KI erzeugt ein Ergebnis, ein Mensch „schaut noch mal“, doch wer tatsächlich entscheidet, bleibt offen.

5. Automation vor Standardisierung

Ein chaotischer Prozess wird automatisiert. Danach läuft er nur schneller und schwerer durchschaubar schief.

6. Keine Pflege

Das Projekt wird einmal eingerichtet und danach wie ein Denkmal behandelt. Quellen veralten, Regeln widersprechen sich, Vorlagen bilden den echten Ablauf nicht mehr ab.

Ein Betriebssystem ist kein einmaliges Setup. Es ist eine lebende Struktur mit stabilen Prinzipien und kontrollierten Änderungen.

Dein Minimalstart für einen Nachmittag

Du brauchst nicht sofort meine ganze Architektur. Beginne mit einem einzigen wiederkehrenden Prozess.

Schritt 1: Ein Projekt wählen

Zum Beispiel: aus einem Experteninterview ein geprüftes Content-Briefing erstellen.

Schritt 2: Fünf Dateien anlegen

1. PROJEKTBRIEFING.md
2. ROLLEN-UND-FREIGABEN.md
3. QUELLEN-UND-MATERIAL.md
4. WORKFLOW.md
5. CHANGELOG.md

Schritt 3: Einen echten Fall durchführen

Nutze dafür keine perfekte Demo, sondern einen realen, aber kontrollierbaren Auftrag.

Schritt 4: Fehler dokumentieren

Wo fehlte Kontext? Welche Rückfrage kam zu spät? Was musste ein Mensch korrigieren?

Schritt 5: Nur die betroffene Regel verbessern

Schreibe nicht aus Begeisterung das ganze System neu, sondern ändere nur die Regel, an der sich eine konkrete Schwäche gezeigt hat.

Das reicht für den Anfang.

Der Sinn eines KI-Betriebssystems besteht nicht darin, besonders komplex auszusehen. Er besteht darin, gute Arbeit wiederholbarer zu machen und schlechte Entscheidungen so zu dokumentieren, dass ihre Spuren sichtbar bleiben.

Aus deinem Prozess ein belastbares System machen

Ein KI-Betriebssystem lässt sich nicht sinnvoll als Universalpaket kopieren. Es muss zu Material, Team, Risiken, Werkzeugen und Freigaben passen.

Ich unterstütze Content-Teams dabei, genau diese Architektur aufzubauen: mit Workflow-Audit, Setup und laufender Qualitätssicherung. Wenn zuerst Themen, Zielgruppen und Prioritäten geklärt werden müssen, ist eine Content-Strategie der bessere Einstieg.

Die praktische Tagesansicht des Systems beschreibe ich in Ein typischer Tag als KI-Operator. Wie aus Originalmaterial ein belastbarer Beitrag wird, zeigt die Journalisten-Methode.

Ein paar klare Sätze zu Ausgangslage, Ziel und Engpass reichen für eine erste Einordnung: Projekt kurz schildern.

Quellen und weiterführende Hinweise

• OpenAI: Projects in ChatGPT
• Anthropic: Was sind Projects in Claude?
• Google: Gems erstellen, verwenden und verwalten
• Anthropic: AI Fluency Framework
• NIST: AI Risk Management Framework – Generative AI Profile

Transparenz: „KI-Betriebssystem“ ist meine Bezeichnung für eine persönliche Wissens- und Prozessarchitektur. Es handelt sich nicht um ein eigenständiges Softwareprodukt und nicht um einen allgemein normierten technischen Begriff.