Prompt-Governance: Warum dein Unternehmen ein internes Prompt-Wiki braucht und wie du es aufbaust

Ein fiktives Beispiel aus dem Projektmanagement: Ein Mitarbeiter entwickelt eine wiederverwendbare Vorgehensweise. Er kopiert unstrukturierte Meeting-Notizen in ein KI-Tool, fügt einen präzisen Prompt hinzu und erhält einen sauberen, strukturierten Entwurf für den Kundenbericht. Ob sie Zeit spart und die Qualität hält, muss das Team anhand echter Vorgänge messen.

Zwei Monate später wechselt dieser Mitarbeiter die Abteilung. Was bleibt, ist die Aufgabe. Die Kollegen kennen weder die genaue Formulierung des Prompts noch die notwendigen Formatierungen der Eingabedaten oder die Kriterien, nach denen das Ergebnis geprüft wurde. Das Team beginnt bei null.

Dieses Szenario ist kein Zeichen mangelnder Kooperationsbereitschaft. Mitarbeiter halten Wissen selten absichtlich zurück. Es fehlt schlichtweg ein definierter Ort und ein klarer Prozess, um KI-Arbeitsweisen zu dokumentieren. Genau hier setzt ein internes Prompt-Wiki an. Wiederverwendbar wird eine KI-Anweisung erst durch dokumentierten Kontext, geprüfte Ergebnisse und klare Einsatzgrenzen.

Was Prompt-Governance praktisch bedeutet

Prompt-Governance definiert die Spielregeln für den betrieblichen KI-Einsatz auf Ebene der konkreten Arbeitsanweisung. Sie klärt konkrete Fragen: Wer darf eine Vorlage für welchen Zweck verwenden? Welche Daten sind erlaubt? Wer prüft das Ergebnis und wer pflegt die Vorlage?

Dabei erfordert nicht jeder spontane Chat mit einer KI einen formalen Prozess. Eine funktionierende Governance unterscheidet vier Stufen:

• Persönliche Experimente: Einmalige Aufgaben oder das Ausprobieren neuer Lösungswege. Die betrieblichen Daten- und Nutzungsregeln gelten auch hier; ein eigener Wiki-Eintrag ist nicht für jeden Versuch nötig.
• Geteilte Entwürfe: Ein nützlicher Ansatz, der im Team-Chat geteilt wird ("Versuch mal diesen Prompt"). Noch ungetestet für Randfälle.
• Geprüfte und freigegebene Vorlagen: Dokumentierte, verlässliche Arbeitsanweisungen für wiederkehrende Prozesse. Hier greift das Prompt-Wiki.
• Technisch eingebundene Workflows: Fest verdrahtete Prozesse per API oder in Fachanwendungen, bei denen der Nutzer den Prompt gar nicht mehr sieht.

Der administrative Aufwand muss zur Wiederverwendung und zu den möglichen Fehlerfolgen passen. Ein Wiki zielt auf Stufe 3: Es wandelt individuelles Ausprobieren in ein verlässliches Unternehmens-Asset um.

Welche Prompts ins Wiki gehören

Die Qualität eines Wikis sinkt mit jedem unbrauchbaren oder doppelten Eintrag. Der Aufbau beginnt daher mit einem kleinen, streng kuratierten Startbestand.

Kriterien für die Aufnahme in das Wiki:

• Wiederkehrende Aufgabe: Der Prozess findet regelmäßig statt (z. B. wöchentliche Berichte, Standard-Kundenanfragen).
• Skalierbarer Nutzen: Die Vorlage hilft mehreren Mitarbeitern oder ganzen Abteilungen.
• Klare Parameter: Eingabedaten und gewünschtes Ergebnis lassen sich eindeutig beschreiben (EVA-Prinzip: Eingabe, Verarbeitung, Ausgabe).
• Prüfbarkeit: Es existieren objektive Kriterien, um die Qualität der KI-Ausgabe fachlich zu bewerten.
• Definierte Grenzen: Es ist klar benennbar, wofür der Prompt nicht geeignet ist.
• Verantwortlichkeit: Eine benannte Person oder Rolle übernimmt die fachliche Pflege.

Was ungeeignet ist:

• Unbearbeitete, seitenlange Chatverläufe ohne extrahierte Kernanweisung.
• Sogenannte "Superprompts" aus dem Internet, die intern nie auf echte Anwendungsfälle getestet wurden.
• Vorlagen, die echte, vertrauliche Beispieldaten (Personenbezug, Geschäftsgeheimnisse) enthalten.
• Minimal abgewandelte Duplikate bestehender Einträge.

So wird das Wiki aufgebaut

Ein Prompt-Wiki ist kein reines Textdokument, sondern eine durchsuchbare Datenbank. Die primäre Sortierung erfolgt nach Aufgaben und Anwendungsfällen, nicht rein nach Abteilungen. Ein Prompt zur Textzusammenfassung nützt dem Marketing ebenso wie dem Vertrieb.

Sinnvolle Ordnungsmerkmale (Metadaten):

• Aufgabe / Zielsetzung
• Zuständiger Fachbereich
• Freigabestatus (Entwurf, Freigegeben, Veraltet)
• Geeignete Umgebung (z. B. lokales Modell, Enterprise-Chat, spezifisches Tool)
• Erlaubte Datenarten (Öffentlich, Intern, Vertraulich)
• Datum der letzten Prüfung

Die Einstiegsseite:

Die Startseite des Wikis muss sofort arbeitsfähig machen. Sie benötigt eine dominante Suchleiste, eine Liste der am häufigsten genutzten Vorlagen, Filter nach Abteilung oder Tool sowie eine Liste der zuletzt aktualisierten Einträge. Ebenfalls wichtig: Ein gut sichtbarer Button, um Fehler zu melden oder neue Prompts vorzuschlagen.

Die Wahl des Werkzeugs:

Führe kein neues Tool ein, wenn die bestehende Umgebung ausreicht.

• Confluence: Eine Option, wenn deine Prozessdokumentation bereits dort liegt. Prüfe Suche, Seitenverantwortung und Freigabestatus in deiner vorhandenen Konfiguration.
• Notion: Wikis unterstützen Seitenverantwortliche und verifizierte Seiten. Welche Funktionen verfügbar sind, hängt vom Tarif ab. Grundlage ist die Notion-Dokumentation zu Wikis.
• SharePoint / Microsoft Lists: Eine Option in einer vorhandenen Microsoft-Umgebung. Prüfe mit der IT, wie Berechtigungen, Versionen und die Suche für deinen Bestand umgesetzt sind.

Die direkt nutzbare Vorlage für einen Wiki-Eintrag

Damit Prompts verlässlich funktionieren, benötigen sie Kontext. Der reine Text des Prompts reicht nicht aus. Jeder Eintrag im Wiki muss zwingend bestimmten strukturellen Vorgaben folgen. (Eine vollständig kopierbare Vorlage für dein Wiki findest du am Ende dieses Artikels).

Die Struktur gliedert sich in folgende Bereiche:

• Identität und Verantwortung: Jeder Prompt benötigt eine eindeutige Kennung, einen klaren Status und einen fachlichen Ansprechpartner. Wenn der Prompt veraltete Ergebnisse liefert, muss klar sein, wer ihn repariert.
• Zweck und Grenzen: Was tut der Prompt und wo liegen seine Limits? Hier wird definiert, welche Datenarten (z. B. keine Kundennamen) strikt ausgeschlossen sind.

Wichtig: Anweisungen im Prompt selbst sind keine verlässliche technische Zugriffskontrolle. Das Wiki regelt das Verhalten der Mitarbeiter, die Technik muss Datensicherheit separat gewährleisten.

• Eingabe und Verarbeitung: Welche Vorarbeiten sind nötig? In welchem Format müssen die Daten vorliegen? Der eigentliche Prompt enthält hier eindeutig bezeichnete Platzhalter (z. B. [EINFÜGEN: Notizen]).
• Ergebnis und Prüfung: Wie sieht das Format der Ausgabe aus? Welche fachlichen Kriterien muss der Mensch zwingend abprüfen, bevor das Ergebnis weiterverwendet wird?
• Technischer Kontext und Pflege: Mit welchem Modell wurde getestet? Gibt es Beispiele für funktionierende Inputs? Wann steht die nächste reguläre Überprüfung an? Ein Wiki darf niemals echte API-Schlüssel, Passwörter oder reale Kundendaten in den Beispielen enthalten. Nutze ausschließlich fiktive oder anonymisierte Daten.

Ein vollständig ausgefüllter Beispieleintrag

Um die Theorie greifbar zu machen, betrachten wir einen risikoarmen, administrativen Anwendungsfall: Die Erstellung eines internen Wochenberichts aus unsortierten Notizen.

Der problematische Testfall: Der Termin am 10.05. liegt vor dem Meeting am 12.05. Das ist ein offener Klärpunkt, kein Beweis für einen falschen Termin. Die Anweisung fordert die KI auf, diese Abweichung sichtbar zu machen. Ob sie das tatsächlich tut, muss der Test zeigen. Der Prompt allein garantiert kein korrektes Ergebnis.

Das Beispiel ist fiktiv und nicht als produktiv getestete Vorlage freigegeben. Die dargestellte Ausgabe beschreibt das gewünschte Ergebnis. Erprobe den Prompt mit deinem freigegebenen Modell, bevor du ihn einsetzt.

Vom Entwurf zur freigegebenen Vorlage

Ein Prompt-Wiki benötigt einen schlanken Lebenszyklus. Ein unnötig großer Freigabeapparat erstickt jede Initiative. In kleinen und mittleren Unternehmen können mehrere dieser Rollen bei derselben Person (z. B. dem Teamleiter) liegen.

• Entwurf: Ein Mitarbeiter erstellt einen Eintrag im Wiki und dokumentiert seinen funktionierenden Prompt samt Beispielen.
• Test: Ein zweiter Kollege (Vier-Augen-Prinzip) nimmt den Prompt, wendet ihn mit eigenen, neuen Daten an und prüft, ob das Ergebnis anhand der Abnahmekriterien reproduzierbar ist.
• Freigabe: Der fachlich Verantwortliche (z. B. Abteilungsleiter) setzt den Status auf "Freigegeben". IT und Datenschutz werden nach den internen Zuständigkeiten beteiligt, insbesondere bei neuen Datenarten, Risiken, Quellen oder Werkzeugen.
• Nutzung: Der Prompt steht dem Team zur Verfügung.
• Überprüfung / Archivierung: Bei Fehlern oder nach Ablauf einer Frist wird der Prompt überarbeitet oder archiviert.

Versionierung und Modellwechsel

Ein Prompt ist keine statische Software. Derselbe Text kann nach einem Update des zugrunde liegenden KI-Modells plötzlich andere Ergebnisse liefern.

Unterscheide zwingend zwischen der reinen Änderungshistorie der Wiki-Seite (Tippfehler korrigiert) und einer ausdrücklich freigegebenen Prompt-Version (Logik geändert). Nutze ein einfaches Schema (v1, v2) und ein kurzes Änderungsprotokoll direkt im Wiki-Eintrag.

Anlässe für erneute Tests:

• Das Unternehmen wechselt den KI-Anbieter oder das zugrunde liegende Modell (Updates verändern oft die Gewichtung von Anweisungen).
• Die Ausgabeanforderungen des Fachbereichs ändern sich.
• Es werden wiederholt fehlerhafte Ausgaben durch Nutzer gemeldet.

Wenn ein Prompt aktualisiert wird, werden die repräsentativen Testfälle von Version 1 in Version 2 eingespeist. Geprüft wird nach fachlichen Kriterien (Erfüllt das Ergebnis die Checkliste?), nicht auf exakt identische Wortwahl der KI.

Achtung bei Copy-and-paste: Mitarbeiter kopieren Prompts oft in ihre privaten Notizen. Das Wiki kann private Kopien technisch nicht aktualisieren. Das Wiki dient als verlässliche "Single Source of Truth". Informiere das Team bei kritischen Updates aktiv, um die Nutzung veralteter privater Kopien zu minimieren.

Warum ein Wiki allein noch keine Nutzung schafft

Ein Werkzeug stiftet erst durch Prozessintegration einen Nutzen. Ein isoliertes Wiki wird schnell zum Friedhof für gute Ideen.

Praktische Maßnahmen zur Etablierung:

• Verlinke die Wiki-Vorlagen direkt dort, wo die Aufgabe entsteht (im Ticket-System, in der Projektmanagement-Software, im CRM).
• Führe kurze Einweisungen anhand echter Arbeitsaufgaben durch, statt abstrakte KI-Schulungen zu halten.
• Nutze verständliche Suchbegriffe und Tags.
• Entferne veraltete oder ungenutzte Einträge radikal. Weniger, aber verlässlicher Inhalt ist mehr wert.
• Schatten-KI beenden – Zeige den Mitarbeitern, dass die offiziellen Vorlagen bessere Ergebnisse liefern als das heimliche Ausprobieren.

Der nächste Schritt: Vom Wiki zum Workflow

Ein Wiki skaliert nicht endlos. Wenn eine Aufgabe sehr häufig anfällt, viele manuelle Variablen erfordert oder Daten direkt in ein Fachsystem geschrieben werden müssen, reicht Copy-and-paste nicht mehr aus. In diesem Fall lohnt sich die Überführung des erprobten Prompts in einen automatisierten Workflow oder ein festes Formular Workflow-Design. Das Wiki dient dann weiterhin als Dokumentation der zugrunde liegenden Logik.

Einführung und Nutzenmessung

Der Aufbau gelingt am besten iterativ. Ein beispielhafter Vier-Wochen-Plan für den Start:

• Woche 1: Bestandaufnahme. Erfasse 3 bis 5 wiederkehrende Aufgaben, für die Mitarbeiter bereits erfolgreich KI nutzen.
• Woche 2: Dokumentation. Überführe diese ersten Anwendungsfälle in das Wiki-Format. Definiere die Abnahmekriterien und teste sie.
• Woche 3: Pilotierung. Eine kleine Nutzergruppe erprobt die Vorlagen im Alltag. Ziel: Identifikation fehlender Erklärungen im Wiki.
• Woche 4: Rollout. Rückmeldungen werden eingearbeitet, die Pflege wird verbindlich Personen zugeordnet. Das Wiki wird offiziell kommuniziert.

Wie misst man den Erfolg?

Die reine Anzahl der Einträge oder Seitenaufrufe belegt keinen geschäftlichen Nutzen. Achte stattdessen auf qualitative Metriken:

• Zeit bis zur Ausführung: Finden Mitarbeiter sofort die passende Vorlage?
• Qualität der Ergebnisse: Sinkt die Nachbearbeitungszeit durch einheitliche Ausgaben?
• Fehlerquote: Treten bestimmte KI-Halluzinationen seltener auf, weil der Prompt sie erfolgreich abfängt?
• Aktualität: Wie hoch ist der Anteil der Vorlagen, deren letzte Prüfung weniger als sechs Monate zurückliegt?

Mache Wissen nutzbar. Wähle heute eine einzelne, wiederkehrende Aufgabe aus deinem Bereich, dokumentiere die Vorgehensweise anhand der untenstehenden Vorlage und lass einen Kollegen den Prozess mit neuen Beispieldaten erproben.

Kopierbare Wiki-Vorlage

# [Titel des Prompts, z. B. PR-01: Projektstatus zu Wochenbericht]

## 1. Identität & Verantwortung
- **ID:** [Eindeutige Nummer, z. B. MKT-04]
- **Fachlich verantwortlich:** [Person oder Rolle]
- **Status:** [Entwurf / Freigegeben / Veraltet]
- **Version:** [z. B. v1.0]
- **Letzte Prüfung am:** [Datum]

## 2. Zweck & Einsatzgrenzen
- **Ziel:** [Was genau soll erreicht werden?]
- **Nicht geeignet für:** [Konkrete Ausschlusskriterien nennen]
- **Erlaubte Daten:** [z. B. Nur interne Daten, keine personenbezogenen Kundendaten]

## 3. Eingabe & Voraussetzungen
- **Erforderliche Vorarbeit:** [Muss der Text vorher bereinigt werden?]
- **Eingabeformat:** [z. B. Stichpunkte, PDF-Text, CSV]
- **Benötigte Tools:** [Freigegebenes Tool, genaue Modellversion und Konfiguration]

## 4. Der Prompt
*Kopiere den Text ab der Markierung. Ersetze die Platzhalter in den Klammern [ ] durch deine Daten.*

--- START PROMPT ---

[HIER DEN PROMPT EINTRAGEN - Klare Anweisungen, Kontext, Regeln und exaktes Ausgabeformat definieren. Platzhalter deutlich machen, z. B. [DATEN HIER EINFÜGEN].]

--- ENDE PROMPT ---

## 5. Abnahme & Ergebnisprüfung
- **Erwartetes Ausgabeformat:** [z. B. Markdown-Tabelle, Fließtext, Code]
- **Zwingend manuell zu prüfen (Checkliste):**
  - [ ] Kriterium 1 (z. B. Wurden Zahlen nicht verändert?)
  - [ ] Kriterium 2 (z. B. Ist das Format exakt eingehalten?)
  - [ ] Kriterium 3 (z. B. Sind fehlende Daten korrekt markiert?)
- **Bei Fehlern:** [Was tun, wenn das Ergebnis unbrauchbar ist? Neu generieren? Parameter anpassen?]

## 6. Technischer Kontext & Historie
- **Getestetes System:** [z. B. M365 Copilot, lokales Modell XY]
- **Bekannte Einschränkungen:** [Worauf reagiert der Prompt empfindlich?]
- **Änderungsprotokoll:**
  - [Datum]: [Was wurde geändert und warum?]

Häufige Fragen

Reicht eine einfache Liste mit Prompts?

Nein. Eine reine Textliste ohne Kontext führt zu Fehlern. Ohne dokumentierte Eingabevoraussetzungen, Einsatzgrenzen und Abnahmekriterien können andere Mitarbeiter die Qualität der Ergebnisse nicht beurteilen oder reproduzieren.

Müssen alle Prompts zentral freigegeben werden?

Nein. Persönliche Experimente brauchen nicht automatisch eine einzelne Prompt-Freigabe. Die Freigabe des Werkzeugs und die betrieblichen Datenregeln gelten trotzdem. Der Aufwand einer Dokumentation und Freigabe lohnt sich nur bei wiederkehrenden Aufgaben, die von mehreren Personen ausgeführt werden oder direkten Einfluss auf die Geschäftsqualität haben.

Wie häufig müssen Vorlagen überprüft werden?

Mindestens bei jedem Modellwechsel oder großen Update der eingesetzten KI-Software. Zusätzlich empfehlen sich anlassbezogene Prüfungen, wenn sich der zugrunde liegende Geschäftsprozess ändert oder Mitarbeiter wiederholt von Qualitätsproblemen bei der Ausgabe berichten.

Wann lohnt sich ein automatisierter Workflow statt eines einzelnen Prompts?

Wenn die Ausführung sehr häufig stattfindet, große Datenmengen verarbeitet werden, eine hohe Fehleranfälligkeit beim manuellen Copy-and-paste besteht oder die Ergebnisse direkt (ohne manuelle Zwischenschritte) in Fachsysteme wie ein ERP oder CRM übertragen werden sollen.