Muss ich programmieren können, um mit KI ein Dashboard zu bauen?

Für den Einstieg nicht; ein Coding-Agent schreibt den pandas- und Streamlit-Code für dich. Du musst deine Daten aber gut genug kennen, um ein paar Summen von Hand nachzuprüfen.

Soll ich für ein Dashboard Streamlit oder Next.js nehmen?

Streamlit, wenn du schnell ein internes Dashboard für dich oder ein kleines Team brauchst. Next.js mit einer Chart-Bibliothek, wenn es Teil eines Produkts für Kunden ist und Login, Berechtigungen und eigenes Design braucht.

Kann ich den Zahlen vertrauen, die die KI berechnet?

Nicht ohne Prüfung. Vergleiche ein paar Kernzahlen wie Gesamtumsatz oder Bestellanzahl mit Excel oder einer SQL-Abfrage, die du selbst geschrieben hast, und stelle sicher, dass Joins keine Zeilen vervielfachen und Summen aufblähen.

Ist es sicher, ein Dashboard mit einer Produktionsdatenbank zu verbinden?

Deutlich sicherer, wenn du einen separaten Datenbanknutzer verwendest, der nur SELECT-Rechte hat. Nutze nach Möglichkeit ein Read Replica oder eine nächtliche Kopie, damit schwere Abfragen das Live-System nicht bremsen.

Darf ich Kundendaten an ein KI-Modell schicken?

Echte Kundendaten in einen Chat zu kopieren ist riskant und meist unnötig. Gib dem Agenten das Schema und anonymisierte Beispielzeilen; der Code verarbeitet die echten Daten auf deinem eigenen Rechner oder Server.

Daten-Dashboard mit KI bauen: aus Excel oder SQL

Um ein Daten-Dashboard mit KI zu bauen, zeigst du einem Coding-Agenten deine Daten und lässt ihn den Analysecode schreiben: Er liest deine Excel-, CSV- oder SQL-Daten mit pandas, bereinigt und fasst sie zusammen und macht daraus in wenigen Stunden ein interaktives Streamlit-Dashboard. Ist das Dashboard Teil eines Produkts, gehst du genauso mit Next.js und einer Chart-Bibliothek vor. Deine Aufmerksamkeit braucht nicht der Code, sondern ob die Zahlen stimmen und ob die Daten privat bleiben.

Dieser Beitrag führt Schritt für Schritt von einer Verkaufstabelle zu einem Dashboard, das du teilen kannst: Tools, der erste Prompt, nur lesende Datenbankverbindung, die Mathematik der KI prüfen und Deployment.

Was wir bauen

Das Ziel ist, einen Excel-Bericht, den du jede Woche von Hand aktualisierst, durch ein Dashboard zu ersetzen, das sich selbst aktualisiert. Ein typisches Vertriebs-Dashboard hat: eine Summe für den Zeitraum, die Veränderung zum Vorzeitraum, ein Diagramm des Monatsumsatzes, Top-Produkte, eine Aufschlüsselung nach Region oder Kanal und einen Datumsfilter.

Wir gehen per Vibe Coding vor: Der Agent schreibt den Code, du beschreibst, was du sehen willst, und prüfst das Ergebnis. Bei Datenarbeit hat dieser Ansatz eine Bedingung: Du musst deine Daten gut genug kennen, um die Zahlen, die er liefert, zu hinterfragen.

Welcher Weg: Streamlit oder Next.js?

Der schnelle Weg: Python, pandas und Streamlit. Eine Python-Datei wird zu einer funktionierenden Weboberfläche. Filter, Tabellen, Diagramme und Kennzahlenkarten brauchen je ein paar Zeilen. Brauchst du ein internes Dashboard für dich, deine Chefin oder ein kleines Team, ist das der kürzeste Weg. pandas liest Excel, CSV und SQL gleich gut.

Der Produktweg: Next.js und eine Chart-Bibliothek. Sollen Kunden das Dashboard sehen und brauchst du Nutzer-Login, Datenberechtigungen pro Nutzer und ein Design, das zu deiner Marke passt, ist eine React-basierte App besser geeignet. Recharts, Chart.js und ECharts sind gängige Optionen. Daten werden auf dem Server in einer API-Route abgefragt, und nur die Zusammenfassung, die der Nutzer braucht, erreicht den Browser.

Bist du unsicher, beginne mit Streamlit. Der Umstieg auf ein Produkt ist viel leichter, wenn du weißt, welche Diagramme die Leute wirklich nutzen.

Schritt 1: Einrichtung

Ein Coding-Agent im Terminal (Claude Code, Codex, Gemini CLI, die CLI von Cursor usw.) und Python genügen:

mkdir sales-dashboard && cd sales-dashboard
git init
python3 -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install pandas openpyxl streamlit plotly
mkdir data && cp ~/Downloads/sales_2026.xlsx data/
echo "data/" >> .gitignore
echo ".env" >> .gitignore

Ich halte data/ von Anfang an aus Git heraus; Kundendaten haben im Repository nichts verloren.

Schritt 2: erst die Daten kennenlernen

Der häufigste Fehler ist, dem Agenten sofort zu sagen „bau mir ein Dashboard“. Bitte ihn, zuerst die Daten zu verstehen. Dieser erste Turn zeichnet nichts; er berichtet nur:

Read data/sales_2026.xlsx with pandas and write me a data report:
- Sheet names, row and column counts per sheet
- Each column’s type, share of empty values and 5 sample values
- Format of date and money columns (any comma decimals or mixed formats?)
- Duplicate rows and likely key columns (such as order ID)
- Anything that looks inconsistent
Don’t change any file and don’t draw charts. Save the report as analysis/data_report.md.

Lies diesen Bericht. Befunde wie „37 Zeilen der Spalte Amount kamen als Text an“ oder „dieselbe Bestell-ID kommt zweimal vor“ betreffen jede Zahl, die danach kommt. Du entscheidest, was Fehler sind und was echt ist (Erstattungen, geteilte Bestellungen); lass den Agenten die Daten nicht durch Raten korrigieren.

Schritt 3: der Dashboard-Prompt

Sind die Daten sauber, bitte um das Dashboard. Schreibe die Fragen auf, die es beantworten muss; die Diagrammtypen kann der Agent vorschlagen:

Write app.py with Streamlit. Data: data/sales_2026.xlsx, sheet "Sales".

Put cleaning in its own function (load_data), cached with st.cache_data.
Refunds (Amount < 0) count towards revenue and are also shown as a separate metric.

The dashboard should answer:
1. Total revenue, order count and average order value for the selected date range
   (each with change versus the same period last year)
2. Monthly revenue trend (line chart)
3. Top 10 products by revenue (horizontal bar)
4. Revenue by region (bar) with a region filter

Rules:
- All calculations in metrics.py as pure functions.
- Write pytest tests for metrics.py using a small sample dataset with hand-calculated results.
- Format money with the right currency symbol and thousands separators.
When done, run the tests and tell me the streamlit run command.

Die Berechnungen in einer eigenen Datei mit testbaren Funktionen zu halten, ist der wichtigste Teil dieses Prompts. Die Oberfläche ist leicht zu ändern; eine falsche Summenfunktion bringt jedes Diagramm durcheinander.

pytest -q
streamlit run app.py

Sieh dir das Dashboard im Browser an und bitte dann um kleine Änderungen: „Die Produktbeschriftungen sind abgeschnitten, mach es horizontal.“ „Setze den Datumsfilter standardmäßig auf diesen Monat.“ Committe nach jeder Änderung, damit du zurückgehen kannst.

Schritt 4: die Datenbank nur lesend verbinden

Liegen die Daten in der Datenbank deiner App statt in einer Tabelle, gilt die wichtigste Regel: Der Nutzer des Dashboards darf nur lesen. Ein separater PostgreSQL-Nutzer:

CREATE ROLE dashboard_reader LOGIN PASSWORD 'a-strong-password-here';
GRANT CONNECT ON DATABASE app TO dashboard_reader;
GRANT USAGE ON SCHEMA public TO dashboard_reader;
GRANT SELECT ON orders, order_items, products TO dashboard_reader;

Lege den Connection String in .env ab (DATABASE_URL=...) und nenne dem Agenten nur den Variablennamen. Ein paar weitere praktische Punkte:

Gewähre nur Zugriff auf die Tabellen, die du brauchst. Enthält die Nutzertabelle E-Mail-Adressen und Telefonnummern und braucht das Dashboard sie nicht, sollte es sie nicht lesen können.
Nutze, wo möglich, ein Read Replica oder eine nächtliche Kopie. Eine schwere Abfrage des Agenten kann das Live-System bremsen.
Setze ein Abfrage-Timeout (statement_timeout in PostgreSQL) und begrenze die Ergebnisgrößen.
Bitte den Agenten, SQL in separaten .sql-Dateien zu halten; so sind Abfragen leichter zu lesen und von Hand auszuführen.

Schritt 5: die Zahlen prüfen

Das ist der wichtigste Abschnitt. Der gefährlichste Fehler eines Dashboards ist nicht, abzustürzen, sondern eine falsche Zahl in einem überzeugenden Diagramm zu zeigen.

Vergleiche die Kernsummen von Hand

Berechne 3–4 Kennzahlen auf anderem Weg: mit einer Pivot-Tabelle in Excel oder einer einfachen SQL-Abfrage, die du selbst schreibst. Zum Beispiel der Umsatz im März:

SELECT SUM(total) FROM orders
WHERE created_at >= '2026-03-01' AND created_at < '2026-04-01'
  AND status <> 'cancelled';

Stimmt das Dashboard nicht überein, geh nicht weiter, bevor du die Differenz erklären kannst. Die Antwort ist meist eine von diesen: Sind Stornierungen enthalten, wo stehen Erstattungen, ist die Steuer enthalten, welche Zeitzone?

Der stille falsche Join

Das ist der SQL-Fehler, den die KI am häufigsten macht und der am schwersten zu entdecken ist:

-- WRONG: each order is repeated once per line item
SELECT SUM(o.total)
FROM orders o
JOIN order_items i ON i.order_id = o.id;

Eine Bestellung mit drei Positionen wird zu drei Zeilen, und o.total wird dreimal addiert. Die Abfrage läuft einwandfrei, das Ergebnis wirkt plausibel, und der Umsatz ist aufgebläht. Die Lösung ist, auf der richtigen Ebene zu aggregieren: entweder nur über orders summieren oder Positionen zuerst pro Bestellung zusammenfassen und dann joinen. Zum Prüfen frage den Agenten:

For each JOIN in this query: is the row count after the join the same as the
row count of the main table before it? Show COUNT(*) and COUNT(DISTINCT o.id).

Unterscheiden sich die beiden Zahlen, vervielfachen sich irgendwo Zeilen.

Weitere Fallen

Datumsgrenzen: BETWEEN '2026-03-01' AND '2026-03-31' auf einer Timestamp-Spalte verpasst den größten Teil des 31. März. Nimm einen halboffenen Bereich.
Zeitzonen: Speichert die Datenbank UTC, landen Bestellungen um Mitternacht am falschen Tag.
Durchschnitt von Durchschnitten: Der Mittelwert der durchschnittlichen Bestellwerte je Region ist nicht der gesamte durchschnittliche Bestellwert.
Fehlende Werte: Zeilen mit NaN fallen bei manchen pandas-Operationen stillschweigend heraus.

Schritt 6: teilen und deployen

Streamlit: Für den internen Gebrauch läuft es auf einem Server oder in einem Docker-Container hinter deinem Firmennetz oder einer Login-Schicht. Streamlit hat auch einen eigenen Hosting-Dienst, aber stelle kein Dashboard mit Kundendaten unter eine öffentliche URL; du solltest wissen, wer Zugriff hat.
Next.js: Deploye auf eine Plattform wie Vercel oder deinen eigenen Server. Prüfe die Authentifizierung und dass jeder Nutzer nur seine eigenen Daten sieht, auf dem Server; nur in der Oberfläche zu filtern ist keine Sicherheit.
Daten aktuell halten: Bei tabellenbasierten Dashboards beendet das Lesen der Datei aus einem gemeinsamen Ordner oder das Laden in eine Datenbank per kleinem nächtlichem Skript die manuellen Updates.

Was die KI häufig falsch macht

Daten durch Raten „korrigieren“: Lücken mit Null füllen, Daten verwerfen, die sie nicht parsen kann. Lass sie jede Bereinigungsregel ausdrücklich aufschreiben und genehmige sie.
Erfundene Spaltennamen: Ohne das Schema zu sehen erfindet sie eine Spalte wie customer_name. Gib ihr das echte Schema.
Zahlenformate: 1.234,56 als 1.234 lesen. Bitte sie, Rohwerte und geparste Werte nebeneinander zu zeigen.
Alles darstellen: Ein Dashboard mit 15 Diagrammen schaut niemand an. Beschränke es auf die Fragen, die zählen.
„Ich habe es geprüft“: Ein Agent, der seinen eigenen Code mit seinem eigenen Test prüft, kann dieselbe falsche Annahme zweimal treffen. Prüfe eine Zahl selbst.

Sicherheit und Datenschutz

Verbindungsdaten in .env, wobei .env und data/ aus Git herausbleiben.
Füge nie ein Passwort oder einen Connection String in den Chat ein. Gib dem Agenten den Variablennamen.
Schicke keine echten Kundendaten an das Modell. Der Agent braucht das Schema und ein paar Beispielzeilen, um Code zu schreiben; anonymisiere die Beispiele oder erzeuge erfundene. Der Code verarbeitet die Daten auf deinem Rechner, nicht das Modell. Deine DSGVO-Pflichten (oder KVKK) für personenbezogene Daten ändern sich dadurch nicht.
Lies die Befehle und das SQL, die der Agent ausführt. Mit dem Nutzer des Dashboards DELETE, UPDATE oder DROP auszuführen sollte ohnehin unmöglich sein; dafür gibt es den Nur-Lese-Nutzer.
Wisse, wer die URL des Dashboards sehen kann. Einen Link zu teilen heißt, die Daten zu teilen.

So mache ich das mit AgentVera

Nichts davon braucht ein bestimmtes Tool. Ich mache diese Art Arbeit in AgentVera, weil es ein paar Datenbankschritte abkürzt:

Datenbank-Manager. Der Datenbank-Manager verbindet sich mit PostgreSQL, MySQL/MariaDB und SQLite. Eine als „read-only“ markierte Verbindung wird auch serverseitig nur lesend geöffnet. Du kannst das SQL des Agenten im SQL-Editor selbst ausführen, um Summen zu vergleichen, und mit EXPLAIN schwere Abfragen erkennen.
Kontrollierter Agentenzugriff. Schaltest du den Agentenzugriff für eine Verbindung ein, führen Agenten, die MCP unterstützen, Abfragen über das Tool agentvera-db aus; sie sehen nie das Passwort, der Modus ist standardmäßig nur lesend, und jede Abfrage wird protokolliert. Der „AI“-Button, der eine Anfrage in SQL umwandelt, sendet Tabellen- und Spaltennamen, keine Tabellenzeilen.
DB Guard. Schreibt der Agent eine Index- oder View-Migration für das Dashboard, scannt DB Guard sie am Ende des Turns und markiert Risiken wie sperrende Index-Builds oder Datenverlust.
Parallele Agenten und Previews. Claude Code kann in einem Pane das SQL und die Kennzahlen schreiben, während Codex in einem anderen an der Oberfläche arbeitet, jeder in einem eigenen Git-Worktree. Preview-Umgebungen starten den Server jedes Worktrees auf einem eigenen Port.
Diff-Review. Das Code-Review wirft vor dem Merge einen zweiten Blick auf die Kennzahlen-Funktionen.

Datenbank-Manager und Agentenzugriff sind in den Plänen Pro und Team enthalten. Mehr zum Prüfen von agentengeschriebenem Code liest du unter KI-Code-Review, zum parallelen Arbeiten unter Git-Worktrees für parallele Agenten.

Kurze Checkliste

Der Agent hat zuerst einen Datenbericht geschrieben, und du hast die Bereinigungsregeln genehmigt
Berechnungen liegen in getrennten, getesteten Funktionen
Mindestens 3 Kernzahlen auf anderem Weg von Hand geprüft
Zeilenanzahl bei jedem JOIN geprüft
Die Datenbankverbindung nutzt einen Nutzer, der nur SELECT darf
.env und data/ nicht in Git, keine Kundendaten ans Modell geschickt
Zugriff auf das Dashboard auf bekannte Personen beschränkt

Fazit

Ein Dashboard mit KI zu bauen beschleunigt das Programmieren, nimmt dir das Denken aber nicht ab. Der Agent schreibt pandas-, SQL- und Streamlit-Code in Minuten; zu entscheiden, welche Zahl stimmt und welche Daten geteilt werden dürfen, bleibt deine Aufgabe. Nimm dir einen Excel-Bericht, den du diese Woche von Hand aktualisierst, bitte den Agenten zuerst um einen Datenbericht, baue das erste Streamlit-Dashboard und prüfe drei Zahlen selbst.