KI in WordPress: schematische Darstellung eines zentralen AI Gateways zur Kostenkontrolle und Governance

KI in WordPress: Kosten kontrollieren, Governance sichern

KI in WordPress verursacht nutzungsbasierte Kosten: Jede Anfrage wird pro Token beim Anbieter abgerechnet. WordPress 6.9 und 7.0 liefern mit Abilities API und nativem AI Client die technische Basis, aber kein Tracking und keine Limits. Ab dem 2. August 2026 greifen zudem die nächsten Pflichten des EU AI Act.

Dieser Leitfaden zeigt, wie Sie Kosten und Compliance zugleich absichern.

Sie planen KI-Funktionen in Ihrem WordPress-Projekt?

Inhaltsübersicht

Warum WordPress eine andere KI-Ausgangslage hat

Das WordPress-Plugin-Ökosystem war über Jahre fragmentiert. Jedes Plugin band seinen eigenen KI-Anbieter an, mit eigenem API-Schlüssel und eigenem Modell.

Das war das eigentliche Problem. Ein SEO-Plugin sprach den einen Anbieter an, ein Übersetzungs-Plugin den nächsten, ein Chatbot einen dritten. Niemand hatte den Gesamtüberblick über Kosten oder Datenflüsse.

Mit WordPress 6.9 hat sich das verschoben. Die Version führt die Abilities API ein, einen zentralen, maschinenlesbaren Registry-Ansatz für WordPress-Funktionen.

WordPress 7.0 baut darauf auf. Es bringt einen nativen AI Client, der API-Schlüssel und Provider-Zugriff über eine zentrale Konfigurationsschicht bündelt (offizielle Release-Notes).

Wie sich dieselbe Kosten- und Governance-Frage im TYPO3-Umfeld stellt, zeigt unser Leitfaden KI in TYPO3: Kosten & Governance.

Wer noch vor der Grundsatzentscheidung steht, ob WordPress oder ein anderes System das richtige Fundament ist, findet die Abwägung im CMS-Vergleich zwischen TYPO3 und WordPress. Dieser Leitfaden setzt voraus, dass die Wahl auf WordPress gefallen ist.

Warum KI-Kosten in WordPress schnell entgleisen

KI in WordPress läuft fast nie über ein eigenes Modell. Plugins binden externe Anbieter wie OpenAI, Anthropic oder Google an, die pro verarbeitetem Token abrechnen.

Das Problem ist nicht der Preis pro Anfrage, sondern die Summe. Eine einzelne Textgenerierung kostet Bruchteile eines Cents.

Ein Beispiel zur Einordnung: Ein Chatbot mit 1.000 Anfragen pro Tag erzeugt bei rund 2.000 Token pro Anfrage etwa 60 Millionen Token im Monat. Mit einem Spitzenmodell sind das mehrere hundert Euro, mit einem kleinen Modell ein Bruchteil davon. Genau diese Differenz bleibt unsichtbar, wenn niemand misst.

Hinzu kommt die Modellwahl. Ein Spitzenmodell kostet pro Token ein Vielfaches eines kleinen Modells. Wer für jede Aufgabe das teuerste Modell nutzt, zahlt für Leistung, die der Anwendungsfall oft nicht braucht.

Eine einfache Routing-Regel reicht meist aus:

  • Meta-Beschreibungen und kurze Texte laufen über ein kleines Modell
  • Longform-Inhalte und komplexe Anfragen über ein größeres.

Wussten Sie, dass ...?

Der größte Kostenhebel bei KI ist meist nicht die Nutzung selbst, sondern die Modellwahl.

In der aktuellen OpenAI-Preisliste (Stand Juli 2026) kostet das kleinste Modell beim Input rund ein Fünfundzwanzigstel des Flaggschiffs.

Beim Output liegt zwischen dem günstigsten und dem teuersten Modell mehr als Faktor 100.

KI-Kosten im Vergleich: $ pro 1 Mio. Input-Token

Quelle: OpenAI, Stand Juli 2026.

Die zwei Wege zur Kostenkontrolle

Für die Umsetzung gibt es zwei grundsätzliche Ansätze. Beide adressieren das Kostenproblem, aber mit unterschiedlicher Philosophie.

Option 1: Der native AI Client von WordPress 7.0

Seit WordPress 7.0 gibt es einen provider-agnostischen AI Client direkt im Core. Er zentralisiert API-Schlüssel und Provider-Konfiguration an einer Stelle.

Die Schlüsselverwaltung läuft über die neue Connectors-Schnittstelle unter Einstellungen. Plugins, die den AI Client nutzen, müssen selbst keine Zugangsdaten mehr verwalten.

Was der native Client leistet, ist Zentralisierung. Den Token-Verbrauch einzelner Anfragen können Entwickler zwar programmatisch auslesen, ein Kosten-Dashboard und harte Usage-Limits bringt der Core aber nicht mit. Ein Monats-Budget pro Plugin steht bislang nur als offener Feature-Wunsch im Projekt-Tracker.

Diese Governance-Funktionen müssen über ein Plugin oder den Betriebs-Layer ergänzt werden.

Option 2: AI Engine als Gateway-Layer

Plugins wie AI Engine von Jordy Meow verfolgen einen umfassenderen Ansatz. Vergleichbare Lösungen existieren im WordPress-Ökosystem ebenfalls, AI Engine dient hier als Beispiel für die Funktionsweise.

Es protokolliert jede Anfrage mit Modell, Token-Zahl und Kosten.

Zusätzlich erlaubt es Rate-Limiting pro Nutzer und Rolle und unterstützt Modell-Routing zwischen günstigen und leistungsstarken Varianten.

Der Unterschied zum nativen Client liegt im Funktionsumfang: Der native Client zentralisiert, AI Engine misst und begrenzt zusätzlich.

Unsicher, welcher Ansatz zu Ihrer WordPress-Architektur passt?

Agentische Workloads als neue Kostendimension

Eine Entwicklung, die es bei klassischen KI-Plugins nicht gab, sind agentische Workloads. Der WordPress MCP Adapter übersetzt registrierte Abilities in Tools des Model Context Protocol.

Dadurch können externe KI-Agenten wie Claude oder ChatGPT WordPress-Funktionen entdecken und ausführen.

WordPress wird damit vom System, das KI aufruft, zum System, das von KI angesprochen wird.

Konkret heißt das zum Beispiel: Ein Agent erstellt Entwürfe, legt Beiträge an und aktualisiert Meta-Beschreibungen automatisch, ohne dass jemand manuell ins Backend geht.

Das hat Folgen für die Kosten. Ein Agent durchläuft mehrere Schritte, liest Kontext und verkettet Aktionen. Das erzeugt deutlich mehr Token als ein einzelner Prompt.

Wer einen MCP-Zugang öffnet, ohne Limits und Logging zu definieren, baut sich eine unkontrollierte Kostenquelle. Kontrolle entsteht durch Sichtbarkeit, dasselbe Prinzip wie beim Patchen. Wie ein strukturierter Betriebsprozess dafür aussieht, zeigt unser Patch-Management Runbook für CMS.

Governance-Pflicht durch den EU AI Act: Alle Termine im Überblick

Die Transparenzpflichten nach Artikel 50 der EU‑Verordnung über Künstliche Intelligenz (EU AI Act) gelten ab dem 2. August 2026 und betreffen unter anderem Chatbots sowie KI‑generierte Texte, Bilder, Audio und Video.

Die Pflichten für Hochrisiko‑Systeme nach Anhang III sind durch den Digital Omnibus auf den 2. Dezember 2027 verschoben worden; für Hochrisiko‑Pflichten im Sinne von Anhang I (eingebettete Hochrisiko‑Komponenten in regulierten Produkten) gilt als Stichtag der 2. August 2028.

Frühere Pflichten, etwa spezifische Anforderungen an Basismodelle/General‑Purpose‑AI, bleiben davon unberührt und gelten bereits seit August 2025.

Für Verstöße sind Strafen bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes vorgesehen.

Wichtig für die Einordnung: Diese Strafrahmen und die schärfsten Pflichten treffen Hochrisiko-Systeme, etwa in Bewerbungsprozessen oder bei Kreditentscheidungen. Ein Chatbot oder automatische Meta-Beschreibungen fallen in der Regel nicht darunter.

Für typische Website-KI gelten vor allem Transparenz- und Dokumentationspflichten. Die praktische Konsequenz ist dieselbe: Wer nicht loggt, kann nicht nachweisen, was sein System getan hat. Und wer heute kein Logging aufbaut, kann später nicht belegen, dass sein Anwendungsfall harmlos war.

Praktisch heißt das: Es braucht Logging, das Anfragen und Antworten dokumentiert. Das Core-Ergebnisobjekt liefert dafür die Rohdaten, die Speicherung und Auswertung bleibt Aufgabe des Betreibers.

EU AI Act – Pflichten und Stichtage im Überblick

Pflicht / BereichGilt abBetroffene Systeme / Beispiele
Transparenzpflichten nach Artikel 50 des EU AI Act2. August 2026Chatbots sowie KI‑generierte Texte, Bilder, Audio und Video (synthetische Inhalte)
Hochrisiko‑Pflichten nach Anhang III (Digital Omnibus)2. Dezember 2027Hochrisiko‑KI‑Systeme u. a. in Beschäftigung, Bildung, Strafverfolgung, Migration und kritischer Infrastruktur
Hochrisiko-Pflichten nach Anhang I2. August 2028KI-Systeme, die als Hochrisiko-Komponente in regulierten Produkten oder Produktbereichen eingebettet sind
Pflichten für Basismodelle / General‑Purpose AI (GPAI)seit August 2025Allgemeine KI‑Basismodelle mit breit einsetzbaren Fähigkeiten (z. B. große Sprachmodelle) mit Dokumentations‑ und Transparenzpflichten

"Governance heißt nicht, KI auszubremsen. Es heißt, zu wissen, was auf der eigenen Infrastruktur passiert. Ohne Logging gibt es ab August 2026 keinen Nachweis."

Sie wollen Token-Tracking und Logging sauber aufsetzen?

Was eine belastbare KI-Governance braucht

Kostenkontrolle und Compliance laufen über dieselben Mechanismen. Wer die folgenden fünf Punkte klärt, hat sowohl die Rechnung als auch die Nachweispflicht im Griff.

5 Punkte für ein kontrolliertes KI-Setup in WordPress:

  • Zentrale API-Schlüssel-Verwaltung. Alle Provider-Zugänge an einer Stelle, nicht über einzelne Plugins verstreut. Der native AI Client schafft die Grundlage dafür.
  • Token-Tracking. Jede Anfrage mit Modell, Token-Zahl und Kosten protokolliert. Ohne Tracking fällt eine Kostenexplosion erst auf der Rechnung auf.
  • Usage-Limits. Feste Obergrenzen pro Tag, Monat oder Projekt. Das Limit ist die Versicherung gegen den überraschenden Vierstelligen.
  • Logging für den Audit-Trail. Anfragen und Antworten dokumentiert, damit nachweisbar ist, was das System getan hat.
  • Rollen und Rechte für MCP-Zugriffe. Jeder MCP-Zugang an klare Berechtigungen gekoppelt. Nicht jeder Agent braucht Schreibzugriff auf alles.

In einem einzelnen WordPress-Projekt sind diese fünf Punkte in einer Stunde durchgesprochen. Bei mehreren Systemen oder verteilten Teams braucht die Abstimmung entsprechend mehr Zeit, sie bleibt aber eine einmalige Investition.

Beides spart später vierstellige Überraschungen und rechtliche Probleme.

Entscheidungshilfe

Die Wahl folgt der Situation, nicht dem Trend.

  • Wer nur Zentralisierung braucht und mit dem Core-Funktionsumfang zufrieden ist, kommt mit dem nativen AI Client aus.
  • Wer Token-Tracking, Limits und Modell-Routing sofort produktiv braucht, kommt mit AI Engine schneller ans Ziel.

Für Projektleiter zählt vor allem eines: der native Client wächst mit dem WordPress-Core, ein Plugin wie AI Engine hängt vom Entwickler ab. Bei einem produktiven Kundensystem gehört diese Abhängigkeit in die Risikobewertung, genauso wie bei jeder anderen Erweiterung.

Sie wollen die Entscheidung nicht allein treffen?

"In WordPress-Projekten läuft KI oft einfach mit. Keiner sieht, welches Modell aufgerufen wird oder was die Token kosten. Das fällt erst auf, wenn man misst."

FAQ - Häufige Fragen: KI in WordPress

Was kostet KI in WordPress?

KI in WordPress verursacht in der Regel keine Lizenzkosten für das Plugin allein, sondern nutzungsbasierte Kosten beim angebundenen Anbieter. Abgerechnet wird pro Token, also pro verarbeiteter Texteinheit. Die tatsächlichen Kosten hängen von Aufgabenvolumen und gewähltem Modell ab.

Was ist der WordPress AI Client?

Der AI Client ist eine seit WordPress 7.0 native Schnittstelle. Er bündelt API-Schlüssel und Provider-Zugriff über eine zentrale Konfigurationsschicht. Plugins können damit verschiedene KI-Anbieter ansprechen, ohne jeweils eine eigene Anbindung zu pflegen.

Wie kontrolliere ich die KI-Kosten in einem WordPress-Projekt?

Über zentrale API-Schlüssel-Verwaltung, Token-Tracking, Usage-Limits und Modell-Routing. Der native AI Client zentralisiert die Konfiguration, Plugins wie AI Engine ergänzen Tracking und Limits. Zusammen machen sie aus einem offenen Budget einen planbaren Posten.

Was ist der WordPress MCP Adapter?

Der MCP Adapter übersetzt registrierte WordPress-Abilities in Tools des Model Context Protocol. Dadurch können externe KI-Agenten WordPress-Funktionen entdecken und ausführen. Das frühere Automattic/wordpress-mcp-Repository wurde Anfang 2026 archiviert; der Adapter ist der Nachfolgeansatz.

Ist KI in WordPress DSGVO-konform nutzbar?

Das hängt vom Anbieter und der Konfiguration ab, nicht von WordPress selbst. Entscheidend ist, welche Inhalte das System verlassen, wo der Anbieter verarbeitet und ob ein Auftragsverarbeitungsvertrag vorliegt. Ab dem 2. August 2026 kommt die Nachweispflicht aus dem EU AI Act hinzu.

Was bedeutet der EU AI Act für WordPress-Betreiber?

Die Transparenzpflichten nach Artikel 50 des EU AI Act gelten ab dem 2. August 2026.

Die Pflichten für Hochrisiko-Systeme nach Anhang III greifen erst ab dem 2. Dezember 2027; für Anhang-I-Systeme verschiebt sich der Stichtag auf den 2. August 2028.

Frühere Pflichten, etwa für Basismodelle, gelten bereits seit August 2025. Die schärfsten Pflichten treffen Hochrisiko-Systeme.

Für typische Website-KI wie Chatbots gelten vor allem die Transparenzpflichten aus Artikel 50, etwa die Kennzeichnung, dass Nutzer mit einer KI interagieren.

Praktisch heißt das: Logging und Audit-Trail sind nicht automatisch gesetzlich vorgeschrieben, aber für die Nachweisbarkeit und saubere Governance dringend sinnvoll.

Fazit: KI in WordPress ist eine Steuerungsaufgabe

KI in WordPress ist 2026 technisch gelöst. Die eigentliche Aufgabe ist nicht die Anbindung, sondern die Steuerung von Kosten und Zugriffen.

Drei Punkte zum Mitnehmen:

  • Token-Tracking und Usage-Limits gehören vor die erste produktive Anfrage, nicht danach.
  • Modell-Routing ist der größte Kostenhebel, weil es Qualität und Preis pro Aufgabe trennt.
  • Logging ist für Hochrisiko-Systeme spätestens ab Dezember 2027 ein Muss. Für Website-KI ist es praktisch notwendig, um die Transparenzpflichten nach Artikel 50 ab August 2026 belegen zu können.

Sie wollen KI sauber in Ihr WordPress-Projekt integrieren?

Quellen und Referenzen

Teilen Sie den Beitrag:

Join Our Newsletter

Nach oben scrollen