Meine digitale Redaktion: Wie 13 KI-Mitarbeiter gemeinsam BlogVoyager betreiben

19.7.2026 · 3 Min. Lesezeit

Hinter BlogVoyager arbeitet eine spezialisierte digitale Redaktion: vom Nachrichten-Scout über Recherche, Fachredaktion und Faktenprüfung bis zur Bildgestaltung und LinkedIn-Aufbereitung. Ich zeige, welche Aufgaben meine KI-Mitarbeiter übernehmen, wie sie zusammenarbeiten und warum die endgültige Entscheidung trotzdem bei mir bleibt.

Eine Redaktion aus spezialisierten KI-Mitarbeitern

BlogVoyager wirkt nach außen wie ein persönliches Fachblog. Hinter den Kulissen arbeitet jedoch eine größere digitale Redaktion. Seine Mitarbeiter sind keine Menschen, sondern spezialisierte KI-Agenten und automatisierte Prüfschritte.

Jeder digitale Mitarbeiter hat eine klar abgegrenzte Aufgabe. Einer sucht nach interessanten Themen, ein anderer bewertet ihre Relevanz, weitere kümmern sich um Recherche, Text, Faktenprüfung, technische Beispiele, Bilder, Übersetzung und LinkedIn.

Ich selbst übernehme die Rolle des Herausgebers und Chefredakteurs. Die digitale Redaktion bereitet Beiträge vor, prüft sie und macht Verbesserungsvorschläge. Veröffentlicht wird aber erst, wenn ich den Artikel kontrolliert und freigegeben habe.

Meine digitalen Mitarbeiter

Nika – Nachrichten-Scout

Nika beobachtet die für BlogVoyager hinterlegten Nachrichtenquellen und Feeds. Ihr Schwerpunkt liegt auf Microsoft Azure, Azure AI Foundry, Azure AI Services, Microsoft Entra, Microsoft 365 Copilot und GitHub Copilot.

Sie sammelt neue Meldungen und erkennt anhand technischer Merkmale, welche Einträge seit dem letzten Lauf hinzugekommen sind. Dabei entscheidet sie noch nicht, ob daraus tatsächlich ein Beitrag entsteht. Ihre Aufgabe ist zunächst, relevante Kandidaten zuverlässig an die nächste Station weiterzugeben.

Theo – Themenanalyst

Theo bewertet jeden neuen Kandidaten anhand von vier Kriterien:

• fachliche Übereinstimmung mit den Themen von BlogVoyager
• Neuigkeitswert
• Relevanz für IT-Entscheider und Cloud-Architekten
• Konkretheit und praktische Umsetzbarkeit

Aus diesen Kriterien entsteht ein Relevanzwert. Meldungen ohne direkten Bezug zu Azure, Microsoft AI, Entra oder Copilot werden aussortiert. Auch allgemeine Marketingtexte ohne technische Substanz sollen nicht in die Redaktion gelangen.

Theo schlägt außerdem passende Tags vor. Dabei verwendet er die vorgegebene Taxonomie des Blogs, damit ähnliche Beiträge konsistent eingeordnet werden.

Dana – Recherchekoordinatorin

Dana verhindert, dass mehrere Medienberichte über dasselbe Ereignis zu mehreren nahezu identischen Artikeln führen.

Dafür werden Titel und Kurzbeschreibung eines Kandidaten in eine mathematische Repräsentation, ein sogenanntes Embedding, umgewandelt. Dana vergleicht dieses Embedding mit bereits verarbeiteten Meldungen und mit anderen Kandidaten aus demselben Scan.

Sind zwei Meldungen semantisch sehr ähnlich, wird nur eine davon weiterverarbeitet. Weitere Fundstellen können als verwandte Quellen erhalten bleiben. Dadurch wird aus mehreren Meldungen über dasselbe Thema ein gemeinsamer Recherchevorgang.

Rhea – Quellenresearcherin

Rhea sucht zusätzliche Quellen, bevor ein Artikel geschrieben oder erneut geprüft wird.

Sie bevorzugt bei Microsoft-Themen offizielle Produktseiten, Microsoft Learn, Azure-Architekturdokumentationen, Preisübersichten und Referenzen der Azure-Befehlszeilenschnittstelle (Azure CLI). Die Recherche ist aber nicht auf Microsoft beschränkt. Wenn ein Thema andere Anbieter, Standards, Studien oder unabhängige Analysen betrifft, darf sie auch geeignete externe Quellen berücksichtigen.

Rhea arbeitet nicht einfach mit Suchtreffern. Gefundene Seiten werden neu abgerufen und ihr verwertbarer Inhalt wird extrahiert. Nicht erreichbare Seiten, Weiterleitungen, ungeeignete Inhalte und Seiten mit zu wenig auswertbarem Text werden dokumentiert oder verworfen.

Armin – Fachautor

Armin erstellt aus dem Ausgangsthema und dem Recherchekontext einen eigenständigen deutschen Fachartikel.

Er soll keine Meldung lediglich umformulieren. Seine Aufgabe ist, das Thema einzuordnen und für die Zielgruppe von BlogVoyager aufzubereiten. Dazu gehören technische Zusammenhänge, Auswirkungen auf Architektur und Betrieb, mögliche Risiken sowie konkrete Handlungsmöglichkeiten.

Quellen und interne Prüfvermerke gehören nicht als störende Formulierungen in den Fließtext. Stattdessen werden Tatsachenbehauptungen und ihre Quellen in einem separaten Faktenblock gespeichert.

Armin erstellt außerdem Titel, Teaser, Gliederung, Tags und eine geschätzte Lesezeit.

Quinn – Qualitätsredakteur

Quinn liest den vollständigen Entwurf mit Abstand zum Autor.

Er prüft unter anderem:

• Ist der Artikel fachlich verständlich aufgebaut?
• Enthält er genügend konkrete Informationen?
• Werden Abkürzungen beim ersten Auftreten ausgeschrieben und erklärt?
• Sind Produktnamen und Fachbegriffe korrekt?
• Passt der Text zur Zielgruppe?
• Wiederholt der Artikel nur eine Quelle oder bietet er eine eigene Einordnung?
• Sind die Tags vollständig und sinnvoll?
• Stimmen Codebeispiele und technische Anweisungen mit dem bereitgestellten Kontext überein?

Quinn darf den Entwurf überarbeiten. Seine Änderungen und Hinweise werden in den Revisionsnotizen festgehalten.

Vera – Faktenprüferin

Vera zerlegt den Artikel in überprüfbare Tatsachenbehauptungen. Meinungen und persönliche Empfehlungen werden nicht wie Fakten behandelt.

Sie unterscheidet verschiedene Arten von Aussagen:

• quantitative Aussagen wie Preise, Daten, Prozentwerte oder Versionen
• kausale Aussagen über Ursache und Wirkung
• Vergleiche zwischen Produkten oder Vorgehensweisen
• kategorische Aussagen über Funktionen und Eigenschaften
• prozedurale Aussagen wie Konfigurationsschritte

Für jede Behauptung sucht Vera im bereitgestellten Quellenkontext nach einem passenden Beleg. Das Ergebnis lautet entweder belegt, unbelegt oder durch eine Quelle widerlegt.

Eine Aussage gilt nicht allein deshalb als belegt, weil Quelle und Artikel dasselbe Produkt erwähnen. Bei einem Vergleich müssen beispielsweise beide verglichenen Seiten aus dem Beleg hervorgehen. Bei Zahlen, Daten und Versionen muss der konkrete Wert in der Quelle vorkommen.

Gabriel – Grounding-Analyst

Gabriel berechnet aus Veras Ergebnissen die Groundedness und Coverage des Artikels.

Groundedness beschreibt, wie zuverlässig die geprüften Aussagen mit den Quellen übereinstimmen. Coverage zeigt, welcher Anteil der erkannten Tatsachenbehauptungen überhaupt belegt werden konnte.

Die Berechnung erfolgt im Backend. Der von einem KI-Modell vorgeschlagene Wert wird nicht ungeprüft übernommen.

Widerspricht eine Quelle einer Aussage, wird die Veröffentlichung gesperrt. Das gilt ebenfalls für unbelegte konkrete Zahlen, Preise, Datumsangaben oder Versionen. Erkennt die Faktenprüfung bei einem technischen Artikel überhaupt keine überprüfbaren Aussagen, behandelt das System dies nicht automatisch als Erfolg. Produktbegriffe, Code, Zahlen und auch die Länge des Artikels dienen als Signale dafür, dass die Prüfung möglicherweise unvollständig war.

Kai – technischer Prüfer

Kai ist für Codeblöcke und technische Befehle zuständig.

Er kontrolliert beispielsweise:

• Befehle der Azure CLI
• verwendete Parameter
• offensichtliche Syntaxfehler
• nicht dokumentierte Optionen
• veraltete oder möglicherweise nur als Vorschau verfügbare Funktionen
• unplausible Software Development Kit-Signaturen

Ein technischer Blocker benötigt einen Beleg aus dem bereitgestellten Dokumentationskontext. Kann der Prüfer seine Beanstandung nicht belegen, wird sie nicht automatisch als harte Veröffentlichungssperre behandelt.

Schlägt die technische Prüfung selbst fehl, wird das sichtbar angezeigt. Ein Prüfausfall darf nicht stillschweigend wie eine erfolgreiche Kontrolle aussehen.

Riva – Überarbeitungsredakteurin

Wenn Vera, Gabriel oder Kai Probleme finden, erhält Riva den Entwurf.

Sie versucht zuerst, die betroffene Aussage anhand der vorhandenen Quellen korrekt und präzise umzuformulieren. Ist keine belegbare Formulierung möglich, entfernt sie die Aussage. Anschließend wird der Artikel erneut geprüft.

Dieser Kreislauf aus Überarbeitung und erneuter Verifikation ist begrenzt. Dadurch wird verhindert, dass ein Artikel endlos zwischen den Prüfschritten hin- und hergeschickt wird.

Mira – Bildredakteurin

Mira kümmert sich um das Titelbild.

Sie kann ein neues Bild mit künstlicher Intelligenz erzeugen oder nach einem verwendbaren Bild suchen. Bei der Bildsuche werden nur Quellen und Anbieter berücksichtigt, bei denen maschinenlesbare Lizenzinformationen vorhanden sind. Herkunft, Lizenz und Entscheidung werden dokumentiert.

Alternativ kann ich selbst ein Bild hochladen. Dabei bleiben Bildauswahl, Alternativtext und Herkunft im redaktionellen Datensatz des Artikels erhalten.

Ella – Übersetzungsredakteurin

Nach der Freigabe erstellt Ella die englische Fassung.

Sie übersetzt nicht nur einzelne Wörter, sondern soll Aufbau, Bedeutung, Fachbegriffe, Code und Links korrekt erhalten. Produktnamen, Befehle und technische Bezeichner dürfen dabei nicht versehentlich verändert werden.

So entstehen aus einem geprüften deutschen Beitrag die deutsche und die englische Veröffentlichung.

Linus – LinkedIn-Redakteur

Linus erstellt aus einem veröffentlichten Artikel einen LinkedIn-Beitrag.

Er fasst nicht einfach nur den Teaser zusammen. Der Beitrag soll mit einem interessanten Einstieg beginnen, die wichtigsten Erkenntnisse in gut lesbaren Absätzen darstellen und Leser zum vollständigen Artikel führen.

Text, Hashtags und Bild können vor der Veröffentlichung nochmals manuell geprüft und bearbeitet werden.

So arbeitet die Redaktion zusammen

Die Zusammenarbeit folgt einer festen Übergabekette:

1. Nika sammelt neue Themen aus den konfigurierten Quellen.
2. Dana entfernt bekannte und semantisch ähnliche Meldungen.
3. Theo bewertet Themenpassung, Neuigkeitswert, Kundenrelevanz und Konkretheit.
4. Rhea ergänzt aktuelle und möglichst belastbare Quellen.
5. Armin erstellt den ersten vollständigen Entwurf.
6. Quinn führt das redaktionelle Qualitätsreview durch.
7. Vera überprüft die Tatsachenbehauptungen.
8. Gabriel berechnet Groundedness und Coverage.
9. Kai kontrolliert enthaltene Codeblöcke und technische Befehle.
10. Riva überarbeitet unbelegte, widersprüchliche oder ungenaue Passagen.
11. Mira bereitet das Titelbild vor.
12. Ella erstellt die englische Fassung.
13. Linus bereitet den LinkedIn-Beitrag vor.
14. Ich prüfe Artikel, Quellen, Vorschau und Bild und entscheide über die Veröffentlichung.

Nicht jeder Artikel benötigt jeden Schritt im gleichen Umfang. Ein Beitrag ohne Code benötigt beispielsweise keine Codeprüfung. Faktenprüfung, Qualitätsreview und meine abschließende Freigabe bleiben jedoch zentrale Bestandteile des Ablaufs.

Technische Basis: Azure AI Foundry und die verwendeten Modelle

Meine digitalen Mitarbeiter laufen nicht als eigenständige virtuelle Maschinen. Technisch handelt es sich um spezialisierte Arbeitsschritte innerhalb einer gemeinsamen Redaktionspipeline. Die KI-gestützten Rollen erhalten jeweils einen auf ihre Aufgabe zugeschnittenen System-Prompt, einen definierten Eingabekontext und ein festgelegtes Ausgabeformat. Andere Rollen, etwa Dublettenprüfung und Score-Berechnung, werden durch deterministische Funktionen im Backend umgesetzt.

Die benötigten KI-Modelle werden über Azure AI Foundry bereitgestellt.

GPT-5 für komplexe redaktionelle Aufgaben

Das Hauptmodell GPT-5 übernimmt Aufgaben, bei denen Textqualität, Kontextverständnis und umfangreiche Überarbeitungen besonders wichtig sind. Dazu gehören:

• Schreiben vollständiger Fachartikel
• redaktionelles Qualitätsreview
• Überarbeitung problematischer Passagen
• Übersetzung ins Englische
• Erstellung der LinkedIn-Beiträge
• Reparatur unbelegter oder widersprüchlicher Aussagen

Je nach Aufgabe wird die Kreativität über unterschiedliche Temperatureinstellungen gesteuert. Faktennahe Überarbeitungen laufen mit einer sehr niedrigen Temperatureinstellung. Redaktionelle Texte und LinkedIn-Beiträge dürfen etwas variabler formuliert werden.

GPT-5 Mini für Analyse und Verifikation

GPT-5 Mini wird für stärker strukturierte und wiederholbare Aufgaben eingesetzt:

• Bewertung neuer Themenkandidaten
• Extraktion und Klassifizierung von Tatsachenbehauptungen
• unabhängige Faktenprüfung
• Kontrolle technischer Codebeispiele
• Entwicklung und Prüfung von Bildkonzepten
• Bewertung von Bildquellen und Lizenzen

Fakten- und Codeprüfungen werden mit einer Temperatureinstellung von 0 ausgeführt, um kreative Abweichungen zu reduzieren. Da auch eine so konfigurierte KI nicht automatisch fehlerfrei arbeitet, verlässt sich BlogVoyager nicht auf einen einzelnen Prüflauf: Quellenrecherche, Faktenprüfung, Codeprüfung, Groundedness- und Coverage-Bewertung sowie gezielte Überarbeitung greifen als mehrstufiges Kontrollsystem ineinander. Abschließend prüfe und genehmige ich den Beitrag persönlich.

Die Antworten werden als strukturierte JSON-Daten angefordert. Der Server validiert diese Ergebnisse und berechnet sicherheitsrelevante Werte wie Groundedness und Coverage selbst. Ein vom Modell vorgeschlagener Gesamtwert wird nicht ungeprüft übernommen.

Text Embedding 3 Large für die Dublettenprüfung

Das Modell text-embedding-3-large erzeugt Embeddings aus Titeln und Kurzbeschreibungen.

Ein Embedding bildet die inhaltliche Bedeutung eines Textes als Zahlenvektor ab. Dadurch kann Dana erkennen, dass zwei unterschiedlich formulierte Nachrichten dasselbe Ereignis behandeln.

Die Ähnlichkeit wird mathematisch über die Kosinus-Ähnlichkeit berechnet. Überschreitet sie den konfigurierten Grenzwert, wird die Meldung als semantische Dublette behandelt.

GPT Image 1 Mini für Titelbilder

Für künstlich erzeugte Titelbilder verwendet Mira gpt-image-1-mini.

Vor der eigentlichen Bilderstellung erzeugt ein Sprachmodell zunächst ein strukturiertes Bildkonzept. Daraus entsteht anschließend der Prompt für das Bildmodell. Stil, Motiv, Bildformat und Alternativtext werden gemeinsam mit dem Entwurf gespeichert.

KI-generierte Bilder können durch technische Herkunftsnachweise des Modellanbieters als KI-Inhalte erkennbar bleiben. Diese Kennzeichnung wird nicht entfernt.

Technische Konfiguration und Zugriffsschutz

Die Modelle sind als getrennte Deployments in einem Azure-AI-Foundry-Konto eingerichtet:

• gpt-5 als Hauptmodell
• gpt-5-mini als Analyse- und Prüfmodell
• gpt-image-1-mini als Bildmodell
• text-embedding-3-large als Embedding-Modell

Die verwendeten Modellversionen sind in der Infrastrukturkonfiguration festgelegt. Ein Versionswechsel erfolgt erst, wenn die aktuelle Modellversion ausläuft. Dadurch soll sich das Verhalten der Redaktion nicht unkontrolliert durch einen automatischen Modellwechsel verändern.

Die Redaktionspipeline läuft in einer Azure Function App. Sie authentifiziert sich gegenüber Azure AI Foundry über eine systemseitig verwaltete Identität. Lokale Schlüsselauthentifizierung ist für das Foundry-Konto deaktiviert. Im Anwendungscode müssen deshalb keine API-Schlüssel für den Modellzugriff gespeichert werden.

Jeder KI-gestützte Arbeitsschritt erhält nur die Informationen, die er für seine Aufgabe benötigt. Die Faktenprüfung bekommt beispielsweise den Artikel und den neu abgerufenen Quellenkontext. Die technische Prüfung erhält zusätzlich die erkannten Codeblöcke und passende Dokumentationsseiten.

Die beschriebenen Mitarbeiter sind damit keine frei agierenden universellen Agenten. Sie sind verständliche Namen für spezialisierte KI-Aufrufe und kontrollierte Backend-Prozesse innerhalb eines festgelegten Workflows. Status, Ergebnisse, Tokenverbrauch, Prüfwarnungen und Revisionshinweise werden zentral gespeichert und im Redaktions-Dashboard zusammengeführt.