Skip to content

Commit 5a90708

Browse files
os-zhuangos-zhuang
authored
Merge pull request #12 from objectstack-ai/blog/expand-extend-existing-systems
blog: expand 'extend existing systems with AI' post (all 7 locales)
2 parents 236d6c7 + 777145e commit 5a90708

7 files changed

Lines changed: 1441 additions & 606 deletions

‎content/blog/extend-existing-systems-with-ai.de.mdx‎

Lines changed: 222 additions & 92 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
title: "Mach dein bestehendes Geschäftssystem KI-nativ — ohne Migration"
3-
description: "Verbinde ObjectOS mit der Datenbank, die du bereits betreibst, modelliere die Tabellen als Objekte und lass KI echte Daten abfragen und bearbeiten — unter deinen Berechtigungen, auf deinen Servern."
3+
description: "Verbinde ObjectOS mit der Datenbank, die du bereits betreibst, lass einen Coding-Agenten die Tabellen als Objekte modellieren und setze KI auf echte Daten — unter deinen Berechtigungen, auf deinen Servern, ohne das Ursprungssystem anzufassen."
44
author: ObjectStack Team
55
date: 2026-05-30
66
tags:
@@ -9,116 +9,246 @@ tags:
99
- Architecture
1010
---
1111

12-
Die meisten „Bring KI in dein Geschäft"-Versprechen setzen stillschweigend
13-
einen Neuaufbau voraus: die Daten in eine neue Plattform heben, die
14-
Workflows neu implementieren, das Team neu schulen. Genau das will niemand.
15-
Das System of Record — das CRM, das ERP, das Ticketing-Tool, das
16-
selbstgebaute Back Office — funktioniert bereits, und genau dort liegen die
17-
Daten schon.
12+
Die meisten „Bring KI in dein Business"-Pitches setzen heimlich einen
13+
Neuaufbau voraus: Daten auf eine neue Plattform heben, Workflows neu
14+
implementieren, das Team umschulen und beten, dass die Migration gelingt.
15+
Genau das will niemand. Das System of Record — das CRM, das ERP, das
16+
Ticketing-Tool, das selbstgebaute Backoffice — funktioniert bereits, und
17+
die Daten liegen längst dort.
1818

19-
ObjectOS vertritt die gegenteilige Haltung. **Du migrierst nicht. Du verbindest.**
19+
ObjectOS nimmt die Gegenposition ein. **Du migrierst nicht. Du verbindest.**
2020

2121
## Die Idee in einem Satz
2222

23-
Richte ObjectOS auf deine bestehende Datenbank, beschreibe die Tabellen, die
24-
dich interessieren, als Objekte, und jeder KI-Agent, jeder Flow und jedes
25-
Dashboard arbeitet sofort mit diesen Daten — automatisch an das richtige
26-
System geroutet, geregelt durch dieselben Berechtigungen, die deine Nutzer
27-
bereits haben.
23+
Richte ObjectOS auf deine bestehende Datenbank, beschreibe die Tabellen,
24+
die dich interessieren, als Objekte — und jeder KI-Agent, jeder Flow, jede
25+
API und jedes Dashboard arbeitet sofort auf diesen Daten, automatisch an
26+
das richtige System geroutet und durch dieselben Berechtigungen geregelt,
27+
die deine Nutzer bereits haben.
2828

29-
Die ursprüngliche Anwendung ändert sich nicht. Die Zeilen wandern nicht.
30-
ObjectOS wird zur KI-nativen, berechtigungsbewussten Oberfläche über dem,
31-
was du bereits betreibst.
29+
Die ursprüngliche Anwendung ändert sich nicht. Die Zeilen bewegen sich
30+
nicht. ObjectOS wird zur KI-nativen, berechtigungsbewussten Oberfläche auf
31+
dem, was du ohnehin betreibst.
32+
33+
## Ein konkretes Bild
34+
35+
Angenommen, dein Vertriebsteam läuft auf einem Postgres-CRM mit 40
36+
Tabellen. Accounts, Kontakte, Opportunities, Positionen, Aktivitäten —
37+
jahrelange echte Daten, eine Produktivanwendung, die deine Reps täglich
38+
nutzen. Die Führung will zwei Dinge: Leute sollen diese Daten *in
39+
natürlicher Sprache befragen* können („Welche Enterprise-Deals sind aus Q2
40+
gerutscht, und wer verantwortet sie?"), und Automatisierungen sollen
41+
sicher darauf agieren.
42+
43+
Die Neuaufbau-Antwort ist ein Sechs-Monats-Projekt. Die ObjectOS-Antwort
44+
ist ein Nachmittag:
45+
46+
1. Die CRM-Datenbank als **schreibgeschützte** Datenquelle verbinden.
47+
2. Einen Coding-Agenten das Dutzend Tabellen, die dich wirklich
48+
interessieren, als Objekte modellieren lassen.
49+
3. Deine Daten befragen und die erste Automatisierung verdrahten.
50+
51+
Niemand fasst das CRM an. Die Reps merken nichts. Du bekommst eine
52+
KI-native Schicht auf exakt denselben Zeilen.
3253

3354
## Wie es heute funktioniert
3455

35-
Es gibt vier Schritte, und keiner davon lautet „bau deine App neu":
36-
37-
1. **Verbinde die Datenbank als Datasource.** Eine Datasource ist eine
38-
benannte Verbindung — Postgres, MySQL, MongoDB, SQLite. Die
39-
Zugangsdaten stammen aus der Umgebung, und die Verbindung kann
40-
schreibgeschützt sein, wenn du zunächst nur analysieren möchtest.
41-
42-
```ts
43-
import type { Datasource } from '@objectstack/spec';
44-
45-
export const BusinessDb: Datasource = {
46-
name: 'business_primary',
47-
label: 'Business System (Postgres)',
48-
driver: 'postgres',
49-
config: {
50-
connection: {
51-
host: process.env.BIZ_DB_HOST,
52-
user: process.env.BIZ_DB_USER,
53-
password: process.env.BIZ_DB_PASSWORD,
54-
database: process.env.BIZ_DB_NAME,
55-
},
56-
},
57-
active: true,
58-
};
59-
```
60-
61-
2. **Modelliere die Tabellen als Objekte** — und du musst sie nicht von
62-
Hand eintippen. Richte einen Coding-Agenten wie Claude Code auf das
63-
verbundene Schema und bitte ihn, pro Tabelle eine Objektdatei auf
64-
Quellebene zu generieren. Unsere
65-
[`hotcrm`](https://github.com/objectstack-ai/hotcrm)-Referenz-App
66-
zeigt die genaue Form dieser Ausgabe: ein `ObjectSchema.create({ … })`
67-
mit typisierten `Field.*`-Definitionen und `Field.lookup(...)` für
68-
Fremdschlüssel. Du prüfst und verfeinerst; das Ergebnis gehört dir.
69-
70-
3. **Binde Objekte an die Datasource** — pro Objekt oder mit einer
71-
Routing-Regel für einen ganzen Namespace:
72-
73-
```ts
74-
datasourceMapping: [
75-
{ namespace: 'biz', datasource: 'business_primary' },
76-
{ default: true, datasource: 'default' },
77-
]
78-
```
79-
80-
4. **Lass die KI arbeiten.** Sobald eine Tabelle ein Objekt ist, arbeitet
81-
die KI-Schicht kostenlos damit. Agenten fragen über ObjectQL ab, das
82-
jedes Objekt zu seiner Datenbank routet — und jede Abfrage läuft als der
83-
**angemeldete Nutzer** und befolgt Berechtigungen auf Objekt-, Datensatz-
84-
und Feldebene.
56+
Vier Schritte, und keiner davon heißt „bau deine App neu".
57+
58+
### 1. Die Datenbank als Datenquelle verbinden
59+
60+
Eine Datenquelle ist eine benannte Verbindung — Postgres, MySQL, MongoDB,
61+
SQLite. Zugangsdaten kommen aus der Umgebung, niemals inline im Code. Wenn
62+
du zuerst nur analysieren willst, richte sie auf eine Read-Replica oder
63+
einen schreibgeschützten DB-Nutzer — Schreibzugriffe sind dann schlicht
64+
unmöglich.
65+
66+
```ts
67+
import type { Datasource } from '@objectstack/spec';
68+
69+
export const BusinessDb: Datasource = {
70+
name: 'business_primary',
71+
label: 'Business System (Postgres)',
72+
driver: 'postgres',
73+
config: {
74+
connection: {
75+
host: process.env.BIZ_DB_HOST,
76+
user: process.env.BIZ_DB_USER,
77+
password: process.env.BIZ_DB_PASSWORD,
78+
database: process.env.BIZ_DB_NAME,
79+
},
80+
},
81+
pool: { min: 1, max: 10 },
82+
active: true,
83+
};
84+
```
85+
86+
### 2. Die Tabellen als Objekte modellieren — mit einem Coding-Agenten
87+
88+
Diesen Schritt erwarten alle als langsam, und das ist er nicht. Du tippst
89+
kein Objekt pro Tabelle von Hand. Du richtest einen Coding-Agenten wie
90+
**Claude Code** auf das verbundene Schema und lässt ihn Introspektion und
91+
ersten Entwurf erledigen. Ein Prompt so schlicht wie:
92+
93+
> „Verbinde dich mit der Datenquelle `business_primary`. Erzeuge für jede
94+
> dieser Tabellen — `accounts`, `contacts`, `opportunities`, `line_items` —
95+
> eine Datei `src/objects/<name>.object.ts` mit `ObjectSchema.create`.
96+
> Mappe SQL-Spalten auf die passenden `Field.*`-Typen, mach aus
97+
> Fremdschlüsseln `Field.lookup(...)` und setze auf jedem Objekt
98+
> `datasource: 'business_primary'`."
99+
100+
Der Agent liest die echten Spalten, Typen und Fremdschlüssel und schreibt
101+
Objektdateien auf Quellcode-Ebene. Unsere
102+
[`hotcrm`](https://github.com/objectstack-ai/hotcrm)-Referenz-App zeigt die
103+
exakte Form dieser Ausgabe:
104+
105+
```ts
106+
import { ObjectSchema, Field } from '@objectstack/spec/data';
107+
108+
export const Opportunity = ObjectSchema.create({
109+
name: 'biz_opportunity',
110+
label: 'Opportunity',
111+
datasource: 'business_primary',
112+
fields: {
113+
name: Field.text({ label: 'Name', required: true }),
114+
account: Field.lookup({ label: 'Account', reference_to: 'biz_account' }),
115+
amount: Field.currency({ label: 'Amount' }),
116+
stage: Field.select({ label: 'Stage', options: [/* … */] }),
117+
close_date: Field.date({ label: 'Close Date' }),
118+
},
119+
});
120+
```
121+
122+
Weil die Ausgabe **gewöhnlicher Quellcode ist, den du besitzt und
123+
commitest**, behältst du die Kontrolle: Spalten, die zählen, behalten;
124+
solche, die du nicht offenlegen willst, weglassen; Labels, Validierungen
125+
und Berechtigungen darüberlegen. Der Agent bringt dich in Minuten zu einem
126+
prüfbaren Entwurf; du machst ihn produktionsreif.
127+
128+
### 3. Objekte an die Datenquelle binden
129+
130+
Jedes Objekt trägt ein `datasource`. Setze es pro Objekt oder deklariere
131+
einmal eine Routing-Regel für einen ganzen Namensraum und lass jedes Objekt
132+
darunter erben:
133+
134+
```ts
135+
datasourceMapping: [
136+
{ namespace: 'biz', datasource: 'business_primary' },
137+
{ default: true, datasource: 'default' },
138+
]
139+
```
140+
141+
Regeln matchen nach Namensraum, Paket oder Objektnamen-Glob; der erste
142+
Treffer gewinnt. Entscheidungen zur Datenresidenz liegen an einer Stelle
143+
statt über Dateien verstreut.
144+
145+
### 4. Die KI arbeiten lassen
146+
147+
Sobald eine Tabelle ein Objekt ist, arbeitet die KI-Schicht gratis darauf.
148+
Die Agenten und Tools von ObjectOS — `list_objects`, `describe_object`,
149+
`query_records`, `aggregate_data` und der Data-Chat-Agent — laufen alle
150+
durch **ObjectQL**, das jedes Objekt an seine gebundene Datenquelle routet
151+
und Filter, Sortierung und Aggregationen *in die Datenbank pushed*, wenn
152+
der Treiber das unterstützt.
153+
154+
Wenn ein Nutzer also fragt:
155+
156+
> „Welche Enterprise-Opportunities sind aus Q2 gerutscht, und wer
157+
> verantwortet sie?"
158+
159+
schaufelt der Agent nicht die ganze Tabelle in den Prompt. Er kompiliert
160+
das zu einer ObjectQL-Abfrage gegen `biz_opportunity` — ein `WHERE` auf
161+
Stage und Abschlussdatum, ein Join auf den Owner — führt es als
162+
`SELECT … WHERE …` auf deinem Postgres aus und antwortet aus den echten,
163+
aktuellen Zeilen. Und entscheidend: Es führt diese Abfrage **als der
164+
angemeldete Nutzer** aus — wenn ein Rep im CRM die Deals einer anderen
165+
Region nicht sehen darf, kann es der Agent auch nicht.
85166

86167
## Warum das sicher ist
87168

88169
Der Einwand gegen „KI auf unseren Geschäftsdaten" lautet immer Governance,
89170
und genau dort leistet die Runtime die Arbeit:
90171

91-
- **KI handelt als der Nutzer, nie über ihm.** Ein Agent sieht genau das,
92-
was die Person dahinter sehen darf — durchgesetzt in der Runtime, nicht
93-
im Prompt.
94-
- **Standardmäßig schreibgeschützt, wenn du es möchtest.** Binde Objekte an
95-
eine schreibgeschützte Verbindung oder einen schreibgeschützten DB-Nutzer.
96-
Analysiere die Produktion sicher; aktiviere Schreibzugriffe bewusst.
97-
- **Alles auditiert.** Jeder Lese-, Schreib- und Eskalationsvorgang — ob
98-
Mensch oder Agent — wird mit Wer, Was, Wann und Warum aufgezeichnet.
172+
- **KI agiert als der Nutzer, nie über ihm.** Ein Agent sieht genau das,
173+
was die Person dahinter sehen darf — Berechtigungen auf Objekt-,
174+
Datensatz- und Feldebene, erzwungen in der Runtime, nicht im Prompt.
175+
- **Standardmäßig schreibgeschützt, wenn du willst.** Binde Objekte an eine
176+
schreibgeschützte Verbindung oder einen DB-Nutzer. Analysiere die
177+
Produktion sicher; aktiviere Schreibzugriffe bewusst, Objekt für Objekt.
178+
- **Alles auditiert.** Jeder Lese- und Schreibvorgang und jede Eskalation —
179+
ob Mensch oder Agent — wird mit Wer, Was, Wann und Warum protokolliert.
99180
- **Deine Daten bleiben in deinem Netzwerk.** ObjectOS läuft in deiner
100-
Umgebung. Geschäftsdaten und Prompts verlassen deinen Perimeter nie.
181+
Umgebung. Geschäftsdaten und Prompts verlassen deine Grenze nie.
182+
183+
## Neuaufbau vs. verbinden
184+
185+
| | Neuaufbau auf neuer Plattform | Verbinden mit ObjectOS |
186+
|---|---|---|
187+
| **Zeit bis zum ersten Nutzen** | Monate | Ein Nachmittag |
188+
| **Risiko für das System of Record** | Hoch — Migration, Dual-Writes, Cutover | Keins — die Quell-App bleibt unberührt |
189+
| **Wo die Daten liegen** | Verschoben | Bleiben genau, wo sie sind |
190+
| **Modellierungsaufwand** | Jede Entität von Hand neu bauen | Agent entwirft Objekte aus dem Live-Schema |
191+
| **Berechtigungen** | Neu gebaut und neu auditiert | Geerbt; KI folgt demselben Modell |
192+
| **Umkehrbarkeit** | Schwer rückgängig zu machen | Datenquelle trennen — nichts hat sich geändert |
193+
194+
## Was du am ersten Tag bekommst
195+
196+
Sobald eine Handvoll Tabellen modelliert und gebunden ist:
197+
198+
- **Analyse in natürlicher Sprache** über Live-Datensätze, berechnet durch
199+
ObjectQL — kein veralteter Export.
200+
- **Gesteuerte Automatisierung.** Flows und Aktionen lesen und (wo erlaubt)
201+
schreiben dieselben Daten, jeder Schritt auditiert.
202+
- **Eine generierte API und Konsole.** REST/GraphQL-Endpunkte und
203+
Admin-Screens stammen aus denselben Metadaten — keine zusätzliche
204+
Integrationsschicht.
205+
- **Ein Berechtigungsmodell.** Die Grenze für Menschen gilt identisch für
206+
KI-Traffic.
207+
208+
## Ausgeliefert vs. kommend
209+
210+
Der obige Ablauf funktioniert **heute** mit ausgelieferten Bausteinen:
211+
Datenquellen, Routing pro Objekt, fähigkeitsbewusstes ObjectQL-Pushdown und
212+
die KI-Agenten-Schicht. Die Objektmodellierung erfolgt mit einem
213+
Coding-Agenten gegen dein verbundenes Schema — genauso, wie die
214+
`hotcrm`-Objekte verfasst wurden.
215+
216+
Eine reichhaltigere, **schlüsselfertige Föderation** — Schema-Import in
217+
einem Schritt, Bindung an extern besessene Schemas und eingebaute
218+
Schreib-Sicherheitsgates — ist unter
219+
[ADR-0015](https://github.com/objectstack-ai/framework/blob/main/docs/adr/0015-external-datasource-federation.md)
220+
(Status: *Proposed*) in aktiver Ausgestaltung. Wir schreiben mehr, sobald
221+
es landet. Bis dahin ist der dokumentierte Weg — verbinden, modellieren,
222+
binden, abfragen — der unterstützte.
101223

102-
## Was ausgeliefert ist vs. was kommt
224+
## Häufige Fragen
103225

104-
Der oben beschriebene Ablauf funktioniert **heute** mit ausgelieferten
105-
Bausteinen: Datasources, Routing pro Objekt, capability-bewusster
106-
ObjectQL-Pushdown und die KI-Agenten-Schicht. Die Objektgenerierung erfolgt
107-
mit einem Coding-Agenten gegen dein verbundenes Schema — auf dieselbe Weise,
108-
wie die `hotcrm`-Objekte erstellt wurden.
226+
**Muss ich jede Tabelle modellieren?** Nein. Modelliere nur die Tabellen,
227+
die KI und Automatisierung anfassen sollen. Der Rest der Datenbank wird
228+
ignoriert.
109229

110-
Eine reichhaltigere, **schlüsselfertige Föderation** — einstufiger
111-
Schema-Import, Bindung an extern verwaltete Schemata und eingebaute
112-
Schreibsicherheits-Gates — befindet sich in aktiver Konzeption unter
113-
[ADR-0015](https://github.com/objectstack-ai/framework/blob/main/docs/adr/0015-external-datasource-federation.md)
114-
(Status: *Proposed*). Wir schreiben mehr dazu, sobald es verfügbar ist. Bis
115-
dahin ist der dokumentierte Weg der unterstützte.
230+
**Schreibt das in meine Produktionsdatenbank?** Nur, wenn du es zulässt.
231+
Bind an eine schreibgeschützte Verbindung oder einen DB-Nutzer, und
232+
Schreiben ist unmöglich; aktiviere es bewusst, pro Objekt, wenn du bereit
233+
bist.
234+
235+
**Gehen meine Daten an einen Modellanbieter?** ObjectOS läuft in deiner
236+
Umgebung, und Abfragen laufen gegen deine Datenbank. Du steuerst, welcher
237+
KI-Anbieter konfiguriert ist und was er sehen darf.
238+
239+
**Was, wenn sich mein Schema ändert?** Lass den Coding-Agenten erneut gegen
240+
das aktualisierte Schema laufen, um die betroffenen Objekte neu zu
241+
generieren oder zu diffen — es sind nur Quelldateien in deinem Repo.
116242

117243
## Probier es aus
118244

119-
- [Data Sources](/docs/configure/data-sources) — der vollständige Authoring-Leitfaden
120-
- [Bestehende Systeme erweitern](/docs/extend-existing-systems) — das Szenario, von Anfang bis Ende
121-
- [KI-Agenten](/docs/build/agents) — deklarative Agenten über deinen Objekten
245+
- [Datenquellen](/docs/configure/data-sources) — der vollständige
246+
Autorenleitfaden
247+
- [Bestehende Systeme erweitern](/docs/extend-existing-systems) — das
248+
Szenario, von Anfang bis Ende
249+
- [KI-Agenten](/docs/build/agents) — deklarative Agenten über deinen
250+
Objekten
122251

123-
Wenn du bereits eine Geschäftsdatenbank hast, bist du fast am Ziel. Verbinde
124-
sie, modelliere ein paar Tabellen und stell deinen Daten eine Frage.
252+
Wenn du bereits eine Geschäftsdatenbank hast, bist du fast am Ziel.
253+
Verbinde sie, modelliere ein paar Tabellen und stell deinen Daten eine
254+
Frage.

0 commit comments

Comments
 (0)