Diese Frage kommt seit Monaten immer öfter. Aus Vereinen, aus dem Mittelstand, aus Geschäftsführungsbüros, in denen jemand „Mit ChatGPT Datenbanken bauen“ auf LinkedIn gelesen hat. Die kurze Antwort: Nein, eine fertige .accdb-Datei sprudelt nicht aus einem KI-Prompt. Die längere Antwort ist viel interessanter — und sie ist der Grund, warum Access in den letzten zwölf Monaten wieder wirtschaftlich geworden ist.
Worum es wirklich geht
Wenn jemand sagt „Access-Datenbank mit KI erstellen“, meint er fast nie das, was er sagt. Drei verschiedene Dinge stecken hinter dem Satz, und sie müssen vorher auseinander sortiert werden, sonst redet man aneinander vorbei.
Erstens: Eine neue Access-Datei aus dem Nichts entstehen lassen, durch einen einzigen Auftrag an die KI. Das funktioniert nicht. Eine .accdb ist eine proprietäre Microsoft-Datei mit Tabellen, Beziehungen, Formularen, Berichten und VBA-Modulen — und es gibt keine Schnittstelle, über die ein Sprachmodell diese Datei strukturell beschreiben und sofort erzeugen könnte. Wer das anbietet, verkauft im Hintergrund etwas anderes: meist eine No-Code-Cloud-Plattform, die Access ablösen soll, nicht ergänzen.
Zweitens: Eine bestehende Access-Anwendung an KI anschließen, sodass sie Fragen in Klartext beantwortet. Das geht. Über MCP, über Connectors, über lokales RAG. Das ist aber kein Bau-Thema, sondern ein Anbindungs-Thema — und passt hier nicht zur Frage.
Drittens: Mit KI als Werkzeug eine Access-Anwendung entwickeln. Schema, T-SQL, VBA. Das ist das, was 2026 tatsächlich wirtschaftlich relevant geworden ist. Genau darum geht es hier.
Warum Access ausgerechnet jetzt wieder rentabel wird
Die naheliegende Empfehlung im Jahr 2026 lautet: „Schmeißt Access raus, nehmt SeaTable, Airtable oder Power Apps, dann habt ihr KI gleich eingebaut.“ Diese Empfehlung ist nicht falsch — sie ist nur teuer. Bei einer fünfköpfigen Geschäftsstelle vielleicht egal. Bei einem Bundesverband mit Ehrenamtlichen, in denen unregelmäßig jemand mal auf die Datenbank zugreifen soll, summieren sich Per-Seat-Lizenzen schnell auf einen mittleren vierstelligen Betrag pro Jahr. Und das ist nur die Plattform — Workflow-Automation mit Power Automate oder Make kommt obendrauf, jede automatisierte Mail kostet wieder.
Access auf dem Bürorechner kostet nichts mehr. Das Office-Paket ist sowieso da. Der SQL Server im Backend ist eine Einmalinvestition oder eine Express-Edition für null Euro. Outlook ist da, Word ist da, Excel ist da — alles über VBA ansprechbar, ohne externe API-Limits, ohne Connector-Lizenzen, ohne dass jemand in Redmond entscheidet, dass eine bestimmte Funktion künftig nur im teureren Plan verfügbar ist.
Der einzige nennenswerte Nachteil von Access war über die Jahre die Entwicklungszeit. Formulare bauen ist mühsam, VBA-Code schreiben ist langsamer als Python, sauberes Datenmodell entwerfen kostet Stunden. Das war der Grund, warum Access-Entwicklung als „zu teuer für kleine Verbände“ galt. Genau diese Rechnung hat sich verschoben.
Was ein Bundesverband mit 30.000 Mitgliedern davon hat
Aus meiner Praxis im norddeutschen Mittelstand und mit bundesweiten Verbänden zeigt sich seit etwa einem Jahr ein Muster, das ich vorher in der Form nicht gesehen habe. Ein katholischer Jugendverband mit knapp 30.000 Mitgliedern und einer kleinen hauptamtlichen Geschäftsstelle ist mein Kunde. Über Jahre wurde die Access-Anwendung nicht aktualisiert — „zu teuer“, hieß es, dafür wurde drumherum viel manuell gemacht: Rechnungen in Word, Lastschriften händisch zusammengetragen, Veranstaltungsanmeldungen über E-Mail-Listen und Excel.
Erste Etappe in den letzten Monaten: Umstellung des Backends auf SQL Server, Access bleibt als Frontend. Saubere Trennung, robuste Datenhaltung, mehrere Bearbeiter gleichzeitig, vernünftige Backups. Das war noch klassisches Handwerk.
Zweite Etappe — und hier wird es wirtschaftlich interessant — ist die laufende Automatisierung. Mitgliederverwaltung, Veranstaltungsverwaltung, Rechnungslauf, SEPA-Lastschriften, alles vorher Handarbeit in Word und Outlook, alles jetzt durch die Datenbank.
Was sich in der Entwicklungsarbeit konkret verändert hat:
- Schema-Entwurf: Was früher ein Tag am Whiteboard war, ist eine Stunde im Dialog mit Claude oder GPT. Tabellen, Beziehungen, Indizes, Constraints. Das Modell schlägt Normalformen vor, weist auf Redundanzen hin, hinterfragt komische Feld-Namen. Am Ende sitzt der Datenarchitekt nicht weniger im Sattel — er kommt nur schneller ans Ziel.
- Stored Procedures und Trigger in T-SQL: Hier ist die Qualität der KI-Generierung 2026 sehr ordentlich. Eine Prozedur für die Beitragsabrechnung über drei Hierarchiestufen mit korrekter Verbuchung der Diözesanumlage, sauberer Fehlerbehandlung und Transaktionsklammer schreibt ein aktuelles Modell auf einen sauberen Prompt in ein paar Minuten — und der Code ist meist auf Anhieb lauffähig.
- VBA für Office-Automatisierung: Outlook-Mails aus Access verschicken, Word-Serienbriefe mit Datensätzen aus der Mitgliederverwaltung erzeugen, Excel-Export für den Wirtschaftsprüfer. VBA-Code ist seit Jahren stabil, die Trainingsdaten der Modelle sind reichlich vorhanden, die Ergebnisse stimmen. Bei Spezialfällen — 64-Bit-Deklarationen, DAO statt ADO, Late Binding — muss man dem Modell im Prompt sagen, was man will. Dann liefert es.
Das Ergebnis ist nicht, dass plötzlich ein Bot programmiert. Das Ergebnis ist, dass ich pro Tag spürbar mehr fertige Funktionen baue als vor zwei Jahren. Bei einem kostensensiblen Verband bedeutet das: Funktionen, die früher außerhalb des Budgets lagen, sind jetzt machbar. Rechnung statt Word. SEPA-Lastschrift statt Excel-Tabelle. Mitgliederabfrage über die Diözesen hinweg statt drei Mal anrufen.
Wo der Ansatz an Grenzen stößt
Drei ehrliche Einschränkungen.
Erstens: Wer eine unaufgeräumte Datenbank hat, bekommt durch KI keine saubere Anwendung, sondern schnelle Folgeschäden. Eine Access-Datenbank mit Feldnamen wie Feld_1, tmp_alt2 und drei Kopien derselben Tabelle in verschiedenen Versionen liefert auch dem besten Modell keinen Kontext, aus dem brauchbarer Code entsteht. Struktur vor KI bleibt der erste Schritt — sonst potenziert sich der Schaden nur schneller.
Zweitens: Formulare bleiben mühsam. Access-Formulare und -Berichte werden über den Designer gebaut, nicht über Textdateien. Hier hilft die KI nur indirekt, etwa beim VBA-Code hinter den Buttons. Das eigentliche Layout sitzt nach wie vor jemand zusammen, der weiß, wo der Speichern-Button hingehört.
Dritter Punkt, der nüchtern bleibt: Die Geschwindigkeit gilt für Entwickler, die das Fach verstehen. Wer den Unterschied zwischen DAO und ADO nicht kennt, merkt nicht, wenn das Modell für einen 32-Bit-Kontext schreibt, obwohl der Rechner 64-Bit ist. Die KI generiert Code; die fachliche Prüfung bleibt beim Menschen. Genau deshalb ist der Vorteil bei erfahrenen Access- und SQL-Server-Entwicklern groß — und bei Laien gefährlich.
Was das für jemanden bedeutet, der das selbst nicht baut
Wenn du Geschäftsführer eines Verbands, eines Vereins oder eines kleinen Mittelständlers bist und seit Jahren das Gefühl hattest, deine Access-Anwendung sei „eigentlich okay, aber Entwicklung lohnt nicht mehr“ — diese Rechnung ist neu zu prüfen. Eine Access-Anwendung, die heute mit dem Stand der Technik weiterentwickelt wird, kostet pro neue Funktion deutlich weniger als noch vor zwei oder drei Jahren. Es ist nicht ungewöhnlich, dass Funktionen, die früher quartalsweise dazukamen, jetzt monatlich entstehen — ohne dass sich das Budget verändert.
Wichtiger noch: Es entstehen keine Folgekosten, die mit jeder Erweiterung mitwachsen. Kein neuer Nutzer kostet eine zusätzliche Lizenz. Keine zusätzliche Automatisierung kostet ein weiteres SaaS-Abo. Was einmal gebaut ist, läuft. Und wenn die Geschäftsstelle in fünf Jahren eine neue Funktion braucht, wird sie nicht beim Plattform-Anbieter beantragt, sondern gebaut.
Das ist die Geschichte, die in „Access-Datenbank mit KI erstellen“ stecken sollte, wenn die Frage ehrlich gestellt wird. Nicht: KI baut. Sondern: Access bleibt wirtschaftlich, weil Entwicklung billiger geworden ist.
Wer wissen will, ob die eigene Access-Anwendung dafür in Frage kommt, kann sich das in einem Schnellcheck anschauen lassen. Ein Tag, schriftlicher Befund, klarer Vorschlag. Erreichbar über sesoft.de/kostenloses-erstgespraech-sichern.
Quellen
- Eigene Projektarbeit für einen katholischen Jugendverband mit knapp 30.000 Mitgliedern (ab 2025)
- Next-Generation Database Interfaces: A Survey of LLM-based Text-to-SQL, IEEE TKDE 2025
- MSAccessChatGPT — Add-In für die OpenAI-Integration im Access-VBA-Editor
- Microsoft Access — Datenbankanwendungen
Über den Autor
Sönke Schäfer entwickelt seit über 25 Jahren Microsoft-Access- und SQL-Server-Anwendungen für norddeutsche und bundesweite KMU sowie Verbände. Sein Schwerpunkt liegt auf der Modernisierung gewachsener Access-Bestände, der Migration nach SQL Server und der wirtschaftlichen Weiterentwicklung mit KI-gestützten Werkzeugen. Mehr zur Person: Sönke Schäfer — Datenschäfer.
