Vor einiger Zeit habe ich für interne Abläufe eine KI-Anbindung in Access gebaut. Ein paar Zeilen VBA, ein WinHTTP-Request gegen die OpenAI-API, Prompt rein, Antwort zurück. Im Test lief das. In der Praxis war ich monatelang unzufrieden — so unzufrieden, dass ich zwischendurch wieder zum manuellen Chat im Browser gewechselt bin. Dieselbe Aufgabe, dieselbe KI, aber von Hand lieferte sie brauchbare Ergebnisse und mein Access-Code nicht.
Es hat gedauert, bis ich verstanden habe, woran das lag. Und die Erklärung ist nicht „schlechter Code“. Sie ist struktureller.
Warum der nackte API-Call enttäuscht
Ein Prompt an die API zu schicken ist trivial. Das ist nicht der schwierige Teil — und genau das ist die Falle. Der schwierige Teil ist alles, was zwischen „funktioniert im Test“ und „läuft beim Kunden“ liegt.
Drei Dinge sind mir nacheinander aufgefallen. Erstens: Modelle ändern sich. Ein Modellname wird abgekündigt, und ich merke es nicht durch eine Ankündigung, sondern durch eine Fehlermeldung im laufenden Betrieb. Zweitens: Kosten ändern sich, und ohne Protokoll kann ich nicht sagen, was eine einzelne Abfrage gekostet hat — geschweige denn, was ein bestimmter Vorgang über einen Monat summiert. Drittens, und das ist der eigentliche Punkt: Nachvollziehbarkeit fehlt komplett. Welcher Prompt lief letzte Woche? Warum war die Antwort gestern besser als heute? Ich konnte es nicht beantworten.
Der manuelle Chat lieferte deshalb bessere Ergebnisse, weil er im Hintergrund einen umfangreichen Rahmen mitbringt — Systemanweisungen, Kontext, teils Gedächtnis. Mein API-Call brachte nichts davon mit. Er war nackt.
Die 13 Layer — und warum die Zahl egal ist
Anstoß für diesen Artikel war ein LinkedIn-Post, der ein „agentisches KI-System“ als 13-Schichten-Architektur beschreibt: Modell, Orchestrierung, Memory, Tools, Observability, Evals, Guardrails, Human-in-the-Loop, Async-Runtime, Auth, Prompt-Versionierung, Kostenkontrolle, Frontend.
Eine Vorbemerkung zur Ehrlichkeit: Die Zahl 13 ist keine kanonische Referenz. Es gibt kein Schichtenmodell für KI-Systeme wie das OSI-Modell für Netzwerke. Wer sucht, findet Dreier-, Sechser-, Siebener- und eben Dreizehner-Modelle, und fast jedes stammt von einem Anbieter, der zufällig genau diesen Stack verkauft. Die konkrete Zahl ist Rhetorik.
Was nicht Rhetorik ist, ist der Kern darunter. Er taucht in jeder dieser Quellen auf: Gescheiterte KI-Projekte scheitern selten am Modell. Sie scheitern daran, dass die Architektur vage bleibt und niemand den Betrieb wirklich verantwortet. Genau das deckt sich mit meiner eigenen Erfahrung. Mein Problem war nie das Modell. Mein Problem waren die fehlenden Schichten drumherum.
Der Wert der 13 Layer liegt also nicht in der Zahl, sondern in der Funktion einer Checkliste. Sie sind nicht 13 Frameworks, die du installieren musst. Sie sind 13 Fragen, die du beantworten solltest, bevor du eine KI-Anbindung produktiv schaltest. Und für eine Access-Umgebung beantwortest du die meisten davon mit einer Tabelle, einer Konvention oder einer Funktion — nicht mit einem zugekauften Stack.
Die 13 Fragen, übersetzt auf Access und HTTP-API
So sieht die Übersetzung aus, wenn die Basis Access VBA plus ein WinHTTP-Request gegen die OpenAI- oder Anthropic-API ist:
- Modell/Inferenz — der WinHTTP-Call selbst, gekapselt in einer zentralen Funktion. Wichtig nur: Der Modellname steht nicht im Code, sondern in einer Konfigurationstabelle.
- Orchestrierung — die VBA-Ablauflogik, die Daten liest, den Prompt baut, den Call auslöst und das Ergebnis zurückschreibt. Das hat jeder schon, der überhaupt etwas gebaut hat.
- Memory/Kontext — der größte Qualitätshebel. Dazu gleich der eigene Abschnitt.
- Tools — VBA-Funktionen, die das Modell über strukturierte Ausgaben anfordern kann. Für die meisten KMU-Fälle reicht erzwungenes JSON, kein Protokoll-Overhead nötig.
- Observability — eine Logtabelle. Der Layer, den fast alle weglassen, und der, dessen Fehlen mich am meisten gekostet hat.
- Evals — eine kleine Tabelle mit Beispiel-Eingaben und erwarteten Eigenschaften der Ausgabe. Vor jeder Prompt- oder Modelländerung einmal durchlaufen lassen.
- Guardrails — Validierung in VBA, bevor das Ergebnis verwendet wird. Kommt valides JSON? Liegt der Wert im erwarteten Bereich?
- Human-in-the-Loop — ein Access-Formular mit „Übernehmen / Verwerfen / Bearbeiten“. Für KMU-Fälle oft die richtige Architektur, nicht der Kompromiss.
- Async-Runtime — der Umgang damit, dass HTTP-Calls das UI blockieren. Synchron mit Statusanzeige oder als nächtlicher Batch.
- Auth/Mandanten — Verwaltung des API-Schlüssels. Nicht im Code, nicht im Klartext in einer Tabelle.
- Prompt-Versionierung — eine Tabelle, die jeden Prompt mit Version, Modell und Parametern hält. Damit ist die Frage „welcher Prompt lief letzte Woche“ mit drei Feldern beantwortet.
- Kostenkontrolle — eine Tages- oder Monatsobergrenze, geprüft vor jedem Call, gespeist aus dem Log.
- Frontend — das Access-Formular. Hat man bereits.
Das Entscheidende an dieser Liste: Sie verlangt keine 13 Microservices. Sie verlangt im Kern drei Tabellen und eine zentrale Funktion. Der Rest sind Konventionen und ein paar Formulare, die ein Access-Entwickler ohnehin baut.
Layer 3, 5 und 11 — wo die Enttäuschung wirklich saß
Drei der 13 Schichten erklären rückblickend, warum mein erster Versuch nicht trug.
Layer 3, Memory/Kontext. Über die API bekommst du erst einmal schlechtere Ergebnisse als im Chat — und das ist kein Modellproblem, sondern fehlender Kontext. „Memory“ zerfällt dabei in vier unterscheidbare Dinge: die statische Systemanweisung (Rolle, Ton, Ausgabeformat), Few-Shot-Beispiele (zwei oder drei vollständige Eingabe-Ausgabe-Paare), die Konversations-History (bei mehrturnigen Abläufen, weil die API zustandslos ist) und Retrieval (relevante eigene Daten, per SQL-Abfrage in den Prompt geholt). Few-Shot-Beispiele aus einer Tabelle waren bei mir der einzelne größte Hebel — sie ersetzen gefühlt den Großteil dessen, was „der Chat einfach besser kann“.
Layer 5, Observability. Eine Logtabelle mit acht Spalten. Ohne sie war jede Frage nach Kosten, Latenz oder Fehlerursache eine Schätzung. Mit ihr ist sie eine Abfrage.
Layer 11, Prompt-Versionierung. Solange der Prompt als String im Code stand, war jede Änderung unsichtbar. Sobald er in einer Tabelle mit Versionsnummer liegt und seine ID ins Log geschrieben wird, ist nachvollziehbar, was wann lief.
Diese drei zusammen sind der Unterschied zwischen „läuft im Test“ und „verantwortbar“. Der Code dafür ist banal — und das ist genau der Punkt. Es ist keine technische, sondern eine strukturelle Lücke.
Der eine Code-Block, der zählt: das Protokoll
Den meisten VBA-Code in diesem Konzept muss man nicht zeigen — ein WinHTTP-Request und ein paar INSERT-Statements sind Alltag. Eine Stelle lohnt sich aber, weil sie der Layer ist, den fast jeder weglässt: das Schreiben ins Protokoll nach jedem Call. Es ist INSERT-only, kein UPDATE — ein Log, das man nachträglich ändern kann, ist kein Log.
' Schreibt einen Protokolleintrag nach jedem API-Call.
' Wird aus der zentralen LLM_Call-Funktion aufgerufen,
' im Erfolgs- wie im Fehlerfall.
Public Sub LLM_LogWrite( _
ByVal PromptID As Long, _
ByVal ModellName As String, _
ByVal TokenIn As Long, _
ByVal TokenOut As Long, _
ByVal LatenzMs As Long, _
ByVal HttpStatus As Integer, _
ByVal KostenEuro As Currency, _
ByVal Fehlertext As String)
Dim db As DAO.Database
Dim sql As String
Set db = CurrentDb
' INSERT-only: ein Protokoll wird nie aktualisiert.
sql = "INSERT INTO tblLLM_Log " & _
"(LogZeit, PromptID, ModellName, TokenIn, TokenOut, " & _
" LatenzMs, HttpStatus, KostenEuro, Fehlertext) " & _
"VALUES (Now(), " & PromptID & ", " & _
SqlText(ModellName) & ", " & TokenIn & ", " & TokenOut & ", " & _
LatenzMs & ", " & HttpStatus & ", " & _
Replace(CStr(KostenEuro), ",", ".") & ", " & _
SqlText(Fehlertext) & ")"
db.Execute sql, dbFailOnError
Set db = Nothing
End Sub
' Hilfsfunktion: maskiert Strings für die SQL-Anweisung.
Private Function SqlText(ByVal s As String) As String
SqlText = "'" & Replace(Nz(s, ""), "'", "''") & "'"
End Function
Der entscheidende Punkt an diesem Code ist nicht die Technik — die ist bewusst schlicht. Er ist, dass ModellName und PromptID mitgeschrieben werden. Damit beantwortet das Protokoll nachträglich genau die drei Fragen, an denen mein erster Versuch scheiterte: Welches Modell lief? Welcher Prompt lief? Was hat es gekostet? Token-Zahlen und Kosten kommen dabei aus dem usage-Feld der API-Antwort, das sowohl OpenAI als auch Anthropic mitliefern.
Warum überhaupt in Access — und nicht in einem Agent-Framework
Die naheliegende Empfehlung 2026 lautet: Nimm ein fertiges Agent-Framework oder eine SaaS-Plattform. Ich rate für KMU bewusst anders, und das hat handfeste Gründe.
Office und VBA sind in vielen Unternehmen ohnehin da und seit Jahren etabliert. Access-Lösungen, die Word, Excel und Outlook automatisieren, sind im Mittelstand weit verbreitet und werden auch die nächsten Jahre bestehen. Warum ein externes Tool einführen — mit neuen Lizenzen, neuem Anbieter, neuem Schulungsaufwand — wenn die KI-Anbindung intern ohne zusätzliche Lizenz funktioniert? Auf Wunsch sogar mit einem lokal laufenden Modell, dann verlässt kein Datensatz das Haus.
Dazu kommt ein Punkt, der mir wichtiger ist als Lizenzkosten: VBA ist transparent. Man kann den Code lesen. Man sieht, was passiert. Ein zugekaufter Agent-Stack ist eine Blackbox mit dreizehn Schichten, von denen man elf nie zu Gesicht bekommt. Wenn die KI-Anbindung in genau dieser transparenten Umgebung entsteht — und die 13 Fragen sauber beantwortet sind — dann ist die Einbindung selbst transparent und abgesichert. Solide KI-Funktionen eröffnen dann Ansätze, die vorher schlicht nicht machbar waren, ohne dass man Kontrolle und Nachvollziehbarkeit dafür eintauscht.
Mein Kerngedanke in einem Satz: Office und VBA sind sowieso da und etabliert — also machen wir auch die KI-Einbindung transparent und so abgesichert, dass sie zuverlässig eingesetzt werden kann.
Wo der Ansatz an Grenzen stößt
Ehrlich bleiben: Diese Architektur ist bewusst Level 1 — Mensch in der Schleife, überschaubare Fallzahlen, ein Access-Frontend als Kontrollpunkt. Für ein vollautonomes System, das ohne menschliche Prüfung tausende Kundenanfragen pro Stunde beantwortet, ist sie nicht gedacht, und Access wäre dafür auch der falsche Unterbau.
Für die allermeisten KMU-Anwendungsfälle ist das aber kein Mangel. Bei Haftungsfragen, bei Nachvollziehbarkeit gegenüber einer Prüfung, bei überschaubaren Mengen ist ein Bestätigungsformular kein Kompromiss, sondern die verantwortbare Architektur. Die 13 Layer auf Access zu übersetzen heißt nicht, einen Hyperscaler-Stack nachzubauen. Es heißt, die drei bis fünf Schichten zu identifizieren, deren Fehlen das konkrete Projekt unzuverlässig macht — und die anderen bewusst klein zu halten.
Was das für jemanden bedeutet, der das nicht selbst baut
Wenn du kein Entwickler bist, ist die praktische Übersetzung diese: Eine KI-Anbindung, die nur aus „Prompt rein, Antwort raus“ besteht, ist ein Prototyp — auch wenn sie im Test funktioniert. Sie wird teuer, wenn keiner die Kosten sieht. Sie fällt aus, wenn sich ein Modell ändert und niemand es bemerkt. Und sie hängt am Kopf der einen Person, die weiß, welcher Prompt gerade läuft.
Eine belastbare Anbindung kostet etwas mehr Aufbau — im Kern drei Tabellen und eine zentrale Funktion — und ist dafür nachvollziehbar, gedeckelt und übergabefähig. Das ist kein technisches Detail. Das ist die Frage, ob die KI-Funktion ein dauerhafter Baustein ist oder ein Risiko, das beim nächsten Personalwechsel sichtbar wird.
Wer eine bestehende KI-Anbindung daraufhin einmal durchsehen lassen möchte — oder von vornherein belastbar aufsetzen will — erreicht mich über sesoft.de/kontakt.
Das Datenmodell auf einen Blick
Im Anschluss an diesen Artikel folgt eine schematische Darstellung des Datenmodells: die drei zentralen Tabellen tblLLM_Config, tblPrompt und tblLLM_Log, ihre Felder und wie sie zusammenhängen. Sie zeigt, wie wenig Struktur nötig ist, um aus einem nackten API-Call eine verantwortbare Lösung zu machen.
Quellen
- Ultrathink Solutions: „The Modern AI Stack: 13 Layers from LLM to Production“ (Februar 2026) — eines der 13-Schichten-Modelle, zugleich Anbieter-Content für eine eigene Plattform.
- AIMultiple: „The 7 Layers of Agentic AI Stack in 2026“ (Januar 2026) — alternatives Schichtenmodell zum Vergleich.
- MindStudio: „What Is an Agentic Operating System? The Six-Layer Infrastructure Stack“ — Sechs-Schichten-Variante.
- Frühere Artikel auf sesoft.de: „Access mit ChatGPT verbinden“ — der praktische Einstieg, auf dem dieser Beitrag aufsetzt.
Autor
Sönke Schäfer entwickelt seit über 25 Jahren Datenbank- und Office-Anwendungen für norddeutsche KMU und berät unter der Marke Datenschäfer (sesoft.de) zur Anbindung von KI an bestehende Access- und SQL-Server-Systeme. Sein Schwerpunkt liegt darauf, KI-Funktionen so in vorhandene Office-Umgebungen einzubetten, dass sie transparent, nachvollziehbar und ohne neue Abhängigkeiten produktiv laufen. Mehr unter sesoft.de/datenschaefer-soenke-schaefer.
