AI-Ready vs. klassisches Kundenportal: Was sich für Stadtwerke wirklich ändert

Klassische Stadtwerk-Kundenportale und AI-Ready-Portale unterscheiden sich fundamental — nicht im Aussehen, sondern in der Maschinenlesbarkeit. Was sich ändert, wenn KI-Agenten zum eigenen Nutzungskanal werden, und welche konkreten Schritte Stadtwerke jetzt gehen sollten.

Es ist 19:43 Uhr an einem Dienstagabend. Ein Kunde Ihres Stadtwerks öffnet seinen KI-Assistenten und tippt: „Meld meinen Stromzählerstand.“ Der Agent startet — lädt die Portalseite, trifft auf eine JavaScript-gerenderte Login-Maske mit CSRF-Token-Schutz, wartet auf den DOM-Aufbau, scheitert an der MFA-Anforderung und gibt nach 8 Sekunden auf: „Ich kann diese Aufgabe nicht automatisch ausführen. Bitte melden Sie sich selbst im Kundenportal an.“

Der Kunde schließt den Assistenten, öffnet einen Browser, loggt sich ein — und fragt sich, wozu er überhaupt einen KI-Assistenten nutzen soll, wenn der ihm bei simplen Alltagsdingen nicht hilft.

Das ist kein Zukunftsszenario. Agenten, die Webportale ansprechen, existieren heute. Die Nutzerbasis ist noch klein — aber die Infrastruktur dafür entsteht gerade, und Stadtwerke mit API-fähigen Portalen werden in 18–36 Monaten einen messbaren strukturellen Vorteil haben.

Was ein KI-Agent sieht, wenn er ein klassisches Stadtwerk-Portal aufruft

Stellen Sie sich vor, ein Kunde beauftragt seinen Assistenten mit folgendem Auftrag: „Prüf meine letzte Jahresabrechnung und beantrag bei Nachzahlung über 200 Euro einen Ratenzahlungsplan.“

Der Agent lädt Ihr Kundenportal. Was er vorfindet:

<div id="root">
  <!-- Anwendung wird initialisiert -->
</div>
<script src="/static/js/bundle.4a91c2.js"></script>

Der gesamte Inhalt ist JavaScript-rendered. Warte auf den vollständigen DOM-Aufbau. Dann erscheint die Login-Maske — Session-Cookie-Pflicht, CSRF-Token, häufig zusätzlich MFA per App oder SMS. Der Agent kann diese Hürde nicht überwinden, ohne Nutzer-Credentials aktiv zu verwalten — was aus Sicherheitsgründen ausgeschlossen ist.

Wenn er die Authentifizierung irgendwie umgehen könnte:

Rechnungsbeträge stehen in einer HTML-Tabelle ohne semantische Attribute
Die Jahresabrechnung ist ausschließlich als PDF abrufbar — kein maschinenlesbares Äquivalent
Ein Ratenzahlungsantrag führt zu einem mehrstufigen Formular mit Pflichtfeldern, clientseitiger Validierung und eigenem CSRF-Token
Das „Hilfe“-Widget öffnet ein Chat-System — keinen API-Endpunkt

Sechs Schritte würde der Agent benötigen, um die Aufgabe zu erfüllen. Vier davon scheitern zuverlässig. Die anderen zwei hängen davon ab, dass sich das Seiten-Layout seit dem letzten Agent-Zugriff nicht verändert hat.

Das Problem sitzt nicht in der Sicherheit — sondern in der Architektur

An dieser Stelle kommt oft der Einwand: „Unser CSRF-Schutz und die MFA sind bewusste Sicherheitsentscheidungen.“ Das stimmt. Und das ist kein Widerspruch zum AI-Ready-Gedanken.

Ein AI-Ready-Portal hat dieselbe Sicherheit — aber eine andere Schicht dafür. Der Agent authentifiziert sich nicht als menschlicher Nutzer über eine Browser-Session, sondern als autorisierte Anwendung über OAuth 2.0 mit granularen Scoped Tokens. Der Nutzer genehmigt einmalig, welche Aktionen sein Agent durchführen darf. Diese Genehmigung ist widerrufbar, auditierbar und scope-begrenzt.

Sicherheit ist kein Gegenargument. Falsch angewendete Sicherheitsarchitektur schon.

Was ein KI-Agent sieht, wenn er ein AI-Ready Stadtwerk-Portal aufruft

Gleicher Auftrag. Anderes Portal. Erster Schritt: Der Agent ruft /.well-known/agents.json ab:

{
  "name": "Stadtwerk Beispielstadt — Kundenportal",
  "version": "1.2",
  "auth": {
    "type": "oauth2",
    "flows": { "authorizationCode": true },
    "tokenEndpoint": "/oauth/token",
    "scopes": {
      "invoices:read": "Rechnungen und Abrechnungshistorie lesen",
      "meter:write": "Zählerstand melden",
      "contracts:read": "Vertragsdaten und Tarifinfos lesen",
      "payments:write": "Zahlungsvereinbarungen beantragen"
    }
  },
  "tools": [
    {
      "name": "get_invoices",
      "endpoint": "/api/v2/invoices",
      "method": "GET",
      "description": "Rechnungsübersicht mit Beträgen und Fälligkeitsdaten"
    },
    {
      "name": "get_invoice_detail",
      "endpoint": "/api/v2/invoices/{id}",
      "method": "GET",
      "description": "Detailansicht einer Jahresabrechnung inkl. Verbrauchskennzahlen"
    },
    {
      "name": "request_payment_plan",
      "endpoint": "/api/v2/payment-arrangements",
      "method": "POST",
      "description": "Ratenzahlungsvereinbarung für offene Beträge beantragen"
    }
  ]
}

Kein Raten, kein HTML-Parsieren, kein Navigieren durch JavaScript-Apps. Der Agent weiß sofort: Welche Operationen sind verfügbar, wie authentifiziere ich mich dafür, und was bekomme ich zurück.

Ab hier läuft der Auftrag in fünf Schritten ab:

Schritt 1 — OAuth-Flow: Der Nutzer autorisiert den Agenten einmalig für invoices:read und payments:write. Token wird sicher gespeichert.

Schritt 2 — GET /api/v2/invoices liefert eine strukturierte Liste aller Rechnungen mit Status, Betrag und Fälligkeit in JSON.

Schritt 3 — Logikprüfung: Nachzahlung 312 Euro — über dem Schwellenwert. Weiter.

Schritt 4 — POST /api/v2/payment-arrangements mit gewünschter Ratenzahl und Startdatum. Antwort: Bestätigung der Vereinbarung mit Referenznummer.

Schritt 5 — Rückmeldung an den Nutzer: „Ich habe einen Ratenzahlungsplan beantragt: drei Raten à 104 Euro, erste Rate am 1. Mai. Soll ich Ihnen die Bestätigung als Dokument speichern?“

Gesamtdauer: 14–22 Sekunden. Ohne Browser. Ohne Formular. Der Nutzer hat delegiert und bekommt ein Ergebnis.

Direkter Vergleich: klassisches vs. AI-Ready Portal

Kriterium	Klassisches Portal	AI-Ready Portal
Erkennbarkeit für Agenten	Kein Discovery-Mechanismus	`agents.json` unter `/.well-known/`
Authentifizierung für Agenten	Browser-Session, CSRF, MFA	OAuth 2.0 mit Scoped Tokens
Datenstruktur	HTML-Tabellen, PDF, JS-rendered	JSON-API, versioniert und dokumentiert
Aktionen durch Agenten	Praktisch nicht möglich	Explizit definierte Tool-Endpunkte
Stabilität bei UI-Relaunch	Bricht bei Layout-Änderungen	Stabil durch API-Versionierung
Auditierbarkeit	Schwer bis nicht möglich	Vollständig via API-Logs
Kanalbreite	Browser als einziger Kanal	Portal + App + Agent + A2A
Proaktive Benachrichtigungen	Nicht vorgesehen	Webhooks und Event-Subscriptions

„Unser Portal hat doch schon eine App — reicht das nicht?“

Gute Frage. Und die ehrliche Antwort lautet: Die Mobile App hilft, aber sie löst das Agent-Problem nicht.

Mobile Apps sprechen in aller Regel interne Backend-APIs an. Das ist technisch die halbe Miete. Aber:

Die APIs sind meist intern, undokumentiert und nicht für externe Agenten konzipiert
Authentifizierung ist device-bound — App-spezifische Tokens, kein offener OAuth-Standard
Es gibt kein Discovery-Dokument, das einem Agenten erklärt, welche Operationen er aufrufen kann
CORS-Konfigurationen erlauben typischerweise nur App-Origins, keine externen Agent-Clients

Eine App-Backend-API ist ein guter Ausgangspunkt. Sie ist noch kein AI-Ready-Portal.

Was sich für Stadtwerke grundlegend verschiebt

Drei Verschiebungen, die tiefer gehen als nur ein neuer Kanal.

Vom Schaufenster zur Programmierschnittstelle

Klassische Kundenportale sind für den menschlichen Besucher optimiert: ansprechend gestaltet, verständlich strukturiert, mit klarer Navigation. Das Portal ist ein Kommunikationsmedium zwischen Mensch und System.

AI-Ready-Portale erweitern diesen Gedanken: Das Portal bleibt für menschliche Nutzer, was es ist — aber es bekommt eine zweite Schicht, die für Maschinen optimiert ist. Nicht entweder-oder. Beides, übereinander.

Die Auswirkung ist konkret: Jede Routineaktion, die ein Agent übernehmen kann, reduziert die Inbound-Last auf Ihr Servicecenter. Zählerstand melden, Abschlagsänderung prüfen, Rechnungsfrage klären — Aufgaben, für die heute ein Mensch in der Leitung landet.

Vom Ereignis zur dauerhaften Verbindung

Ein Portalbesuch ist situativ: Der Kunde kommt, weil er etwas braucht. Das ist reaktives Service-Design — und es funktioniert, solange der Kunde aktiv handelt.

Eine API-Verbindung ist dauerhaft verfügbar. Wenn der Agent eines Kunden einmal weiß, unter welchen Endpunkten er Rechnungen, Verbrauch und Vertragsstatus abrufen kann, nutzt er diese Verbindung bei Bedarf — ohne dass der Kunde aktiv daran denken muss. Das verändert nicht nur den Kanal, sondern die Qualität der Kundenbeziehung.

Vom Warten auf Kontakt zum proaktiven Signal

Klassische Portale sind darauf ausgelegt, dass der Kunde kommt. Webhook-fähige AI-Ready-Portale können auch umgekehrt funktionieren: Das System sendet ein Signal, wenn etwas Relevantes passiert.

Eine Rechnung steht bereit — der Agent des Kunden bekommt die Nachricht, prüft den Betrag, vergleicht mit dem letzten Jahr und meldet zurück, bevor der Kunde überhaupt daran gedacht hat. Eine Störung im PLZ-Bereich wird erkannt — der Agent weiß es, bevor der Kunde anruft.

Das ist kein Science-Fiction-Feature. Es ist ein Webhook-System mit sinnvoll definierten Ereignis-Typen. Technisch überschaubar, strategisch bedeutsam.

Die nüchterne Einschätzung: Wo stehen wir heute?

Ehrliche Bestandsaufnahme: Der Anteil von KI-Agenten am Gesamttraffic von Stadtwerk-Kundenportalen ist heute marginal. Die Nutzerbasis, die Alltagsaufgaben per Assistent delegiert, liegt noch unter einem Prozent der Kundschaft.

Das ist kein Argument gegen eine frühe Investition. Es ist das Argument dafür.

Infrastrukturentscheidungen, die unter Zeitdruck getroffen werden, sind teurer und fehleranfälliger als solche, die in Ruhe geplant werden. Die Standards entstehen gerade — Google experimentiert mit WebMCP in Chrome, Anthropic hat das Model Context Protocol veröffentlicht, Microsoft Copilot integriert externe APIs in Millionen von Unternehmensarbeitsplätzen. Wer wartet, bis der Druck von außen kommt, zahlt mehr — für Technik und für Organisationsaufwand.

Stadtwerke, die heute eine API-Strategie entwickeln, tun das zu einem Zeitpunkt, an dem die Entscheidungen noch sauber durchdacht werden können und keine Notfallarchitektur nötig ist.

Was ein AI-Ready Stadtwerk-Portal konkret braucht

Kein Komplett-Relaunch. Eine API-Schicht auf dem, was bereits existiert.

Grundlage — Stufe 1

agents.json — Discovery-Dokument unter /.well-known/agents.json mit Tool-Definitionen, Auth-Metadaten und verfügbaren Scopes
OAuth 2.0 mit Scoped Tokens — separate Auth-Schicht für maschinenbasierte Zugriffe, entkoppelt von der bestehenden Session-Authentifizierung
Lese-Endpunkte für die häufigsten Abfragen: aktuelle Rechnung, Rechnungshistorie, Zählerstand-Historie, Vertragsstatus, Tarifdetails
Schreib-Endpunkte für Standardaktionen ohne Medienbruch: Zählerstand melden, Kontaktdaten aktualisieren, Abschlagsänderung beantragen
CORS-Konfiguration für definierte Agent-Origins
API-Versionierung von Anfang an — damit spätere Erweiterungen keine bestehenden Integrationen brechen

Erweiterung — Stufe 2

Webhook-System für ereignisgesteuerte Benachrichtigungen: Rechnung bereitgestellt, Verbrauchsanomalien, Störungsmeldungen mit PLZ-Eingrenzung
Erweiterte Schreib-Endpunkte: Tarifwechsel beantragen, SEPA-Mandat verwalten, Ratenzahlungsvereinbarung abschließen
Agent-Traffic-Monitoring — separates Logging und Fehlerauswertung für maschinellen Zugriff, unabhängig vom Portal-Frontend-Tracking
agent-card.json für A2A-fähige Szenarien, in denen Agenten untereinander kommunizieren

Vorerst nicht erforderlich

Eigener MCP-Server mit Custom-Protocol-Stack
Real-Time-Streaming für Verbrauchsdaten (außer bei direkter Smart-Meter-Anbindung)
Komplexe Multi-Agenten-Orchestrierung innerhalb des Portals selbst

Was ich für Sie entwickle

Stadtwerke brauchen keinen neuen Portal-Vendor und kein Greenfield-Projekt, um AI-ready zu werden. Was fehlt, ist die klare API-Strategie und die richtigen Integrationsbausteine auf bestehenden Systemen.

OAuth-2.0-Authentifizierungsschicht — Scoped-Token-Infrastruktur auf Basis Ihres bestehenden Identity-Providers (Keycloak, Entra ID, Auth0), ohne die bestehende Portal-Authentifizierung anzutasten.

REST-API-Gateway auf Stadtwerk-Backends — Strukturierte API-Schicht auf SAP IS-U, Schleupen CS.ERP, WILKEN Energie oder anderen eingesetzten Branchensystemen. Keine Ablösung — saubere Adapter mit definierten Datenmodellen und versionierten Endpunkten.

Discovery-Dokumente — agents.json und agent-card.json nach aktuellem Standard, damit KI-Agenten das Portal sofort erkennen und korrekt nutzen können.

Webhook-Infrastruktur — Event-basiertes Benachrichtigungssystem für die relevantesten Kundenereignisse, das auch intern als Microservice-Backbone nützlich ist, unabhängig vom Agenten-Traffic.

Agent-Monitoring-Dashboard — Separates Logging und Metrik-Tracking für maschinellen Portalverkehr, damit Ihr Team versteht, welche Endpunkte wie oft genutzt werden und wo Optimierungsbedarf entsteht.

Die bestehende Portaloberfläche bleibt unberührt. Menschliche Nutzer merken nichts. Das ist Nachrüsten — kein Umbau.

Fazit

Klassische Stadtwerk-Kundenportale sind solide gebaut und erfüllen ihren Zweck — für menschliche Nutzer, die einen Browser öffnen. Aber KI-Agenten werden ein zweiter eigenständiger Nutzungskanal, und der funktioniert nur, wenn hinter dem Portal strukturierte APIs und standardisierte Authentifizierung stehen.

Die Adoption ist ein Mehrjahresprozess, kein akuter Notfall. Aber die Infrastrukturentscheidungen fallen jetzt. Stadtwerke, die heute eine API-Strategie entwickeln, tun das zu einem Zeitpunkt, an dem der externe Druck noch gering ist und Architekturentscheidungen sauber durchdacht werden können. Wer wartet, bis die Anforderungen von außen kommen, baut unter Zeitdruck — teurer und mit mehr technischer Schuld.

Wenn Sie wissen wollen, wie AI-ready Ihre aktuelle Portal-Infrastruktur ist und welche Schritte für Ihre Systemlandschaft sinnvoll wären, sprechen Sie mich an. Ich berate Stadtwerke und kommunale Versorgungsunternehmen konkret zu API-Strategie, Integrations-Architektur und AI-Readiness-Implementierung — ohne Pauschalempfehlung, mit Blick auf das, was bereits existiert.