Anwendungsfälle
Baut und betreibt KI-gebaute Apps in eurer Private Cloud
KI-gestütztes Tempo, eure Infrastruktur. Baut mit dem vollständigen Ciao-Delivery-Loop und stellt in euer eigenes AWS-, Azure- oder GCP-Konto oder eine private VPC bereit.
Private-Cloud-Apps sind Anwendungen, die mit KI-gestütztem Engineering gebaut, aber in Infrastruktur bereitgestellt werden, die ihr kontrolliert — euer eigenes AWS-, Azure- oder GCP-Konto oder eine private VPC unter separaten Bedingungen. Ciao baut sie als echte React-, TypeScript- und Supabase-Anwendungen mit automatisierter QA, Live-Sicherheitstests und Guardrails-Governance. Anders als KI-Builder, die nur auf ihrer eigenen Cloud hosten, trennt Ciao, wo Software gebaut wird, von dem, wo sie läuft, sodass Data Residency und Netzwerkgrenzen euch gehören.
Veröffentlicht 2026-07-03 · Zuletzt aktualisiert 2026-07-03
Manche Anwendungen können nicht in der Cloud eines anderen leben
Für viele Teams ist es eine Nebensächlichkeit, wo eine App gehostet wird. Für andere ist es die erste Frage: Die Daten sind reguliert, Residenz ist vertraglich festgelegt, das Security-Team verlangt, dass Traffic innerhalb der Unternehmensnetzwerkgrenze bleibt, oder eine Kundenvereinbarung benennt die Region und das Konto, in dem der Workload laufen muss. Diese Einschränkungen haben KI-App-Builder historisch von vornherein disqualifiziert — die meisten bauen und hosten in einem untrennbaren Paket, auf ihrer Infrastruktur, zu ihren Bedingungen.
Das Ergebnis ist ein frustrierender Trade-off: Fachbereiche sehen, wie Kollegen KI-gebaute Tools in Tagen ausliefern, während ihre eigenen Anfragen hinter Infrastruktur- und Compliance-Review anstehen, weil die schnellen Tools nicht dort bereitstellen können, wo Richtlinie es verlangt, und der Pfad, der korrekt bereitstellt, handgebaut und langsam ist.
Ciao trennt die beiden Hälften. Software wird auf der Plattform gebaut — der Builder, die KI-Softwareorganisation, QA, Security und Guardrails greifen alle — und wird in der Ciao-Cloud, eurem eigenen AWS-, Azure- oder GCP-Konto oder einer privaten VPC unter separaten Bedingungen bereitgestellt. Euer Cloud-Team behält das Konto, die Netzwerkgrenze, die Region und die Schlüssel. Eure Fachbereiche behalten das Build-Tempo. Das Security-Review bekommt echte Antworten: SOC 2 Type II Berichte unter NDA, SSO via SAML und OIDC, rollenbasierte Zugriffskontrolle und ein unveränderlicher Audit-Trail über den gesamten Lebenszyklus.
Was Private-Cloud-Deployment üblicherweise verlangt
Wenn das Ziel eure eigene Cloud ist, wird die Anforderungsliste von euren Plattform- und Security-Teams geschrieben:
- Euer Konto, eure Grenze — Workloads, bereitgestellt in eurem eigenen AWS-, Azure- oder GCP-Konto oder einer privaten VPC, innerhalb des Netzwerkperimeters und der Kontostruktur, die ihr bereits regelt.
- Data Residency — Daten bleiben in der Region, die eure Verträge und Regulatoren benennen — mit Multi-Region-Unterstützung und Data-Residency-Optionen in der Plattform.
- Identitätsintegration — SSO via SAML oder OIDC gegen euren Identity-Provider, optionale MFA und rollenbasierte Zugriffskontrolle, abgestimmt auf eure Verzeichnisgruppen.
- Auditierbarkeit — Ein unveränderlicher Audit-Trail über Prompts, Merges, Deployments und administrative Aktionen — Nachweis, der eurem internen Audit genügt, nicht nur der Neugier.
- Operative Passung — Deployment-Triage, Drift-Erkennung, Rollback und Abgleich über SysOps, plus Doctors nur lesende Diagnose der Live-App.
- Beschaffungsantworten — SOC 2 Type II unter NDA, Zero-Retention-Modellverträge, kein Training an Kundencode und separate Bedingungen für VPC-Deployment, die eure Rechtsabteilung prüfen kann.
Wie ein Private-Cloud-Build abläuft
1. Das Ziel vereinbaren
Euer Cloud-Konto oder eine private VPC, die Region und die Bedingungen — VPC- und On-Prem-Deployment laufen unter separaten, mit dem Vertrieb eingegrenzten Bedingungen.
2. Auf der Plattform bauen
Teams beschreiben Anwendungen in einfacher Sprache und formen sie in Live-Vorschau — die Bau-Erfahrung ist identisch, unabhängig davon, wo die App später läuft.
3. Identität früh integrieren
SSO via SAML oder OIDC, MFA-Optionen und rollenbasierte Zugriffskontrolle werden vor dem Launch gegen euren Identity-Provider verdrahtet, nicht danach.
4. Mit QA und Sicherheit gaten
Deterministische Browser-Replays, Smoke-Gates, statische Analyse, Abhängigkeitsprüfungen und Zugriffskontroll-Proben, bestätigt gegen die Live-App.
5. Änderungen kontrollieren
Guardrails wendet eure Richtlinien in einfacher Sprache an und protokolliert menschliche Prüfung, mit dem Audit-Trail, den eure Compliance-Funktion erwartet.
6. In euer Konto bereitstellen
Die Anwendung wird in eurem AWS-, Azure- oder GCP-Konto oder einer privaten VPC ausgeliefert — innerhalb eurer Grenze, unter euren Kontrollen.
7. Mit geteilter Sichtbarkeit betreiben
Doctor diagnostiziert Live-Probleme nur lesend; SysOps übernimmt Drift, Rollback und Abgleich; Conductor zeigt die Fleet, wenn ihr viele Apps auf diese Weise betreibt.
Sicherheits- und Governance-Checkliste
- ✓ Deployment in euer eigenes AWS-, Azure- oder GCP-Konto oder eine private VPC unter separaten Bedingungen
- ✓ Data Residency eingehalten mit Multi-Region-Unterstützung
- ✓ SSO via SAML oder OIDC, optionale MFA, rollenbasierte Zugriffskontrolle
- ✓ Unveränderliches (append-only) Audit-Protokoll über Prompts, Merges, Deployments und administrative Aktionen
- ✓ Sicherheitsbefunde bestätigt gegen die Live-App, bevor sie gemeldet werden
- ✓ SOC 2 Type II Berichte unter NDA für das Beschaffungs-Review verfügbar
- ✓ Kein Training an Kundencode; Zero-Retention-Modellverträge
Was Teams in ihrer Private Cloud betreiben
Regulierte interne Tools
Freigabe-Workflows, Fallmanagement und Datenhandhabungs-Tools, die laut Richtlinie innerhalb der Unternehmensgrenze bleiben müssen.
Kundenportal im eigenen Konto
Ein kundenseitiges Portal, bereitgestellt im selben Cloud-Konto wie die Systeme, aus denen es liest, hält Datenpfade kurz und auditierbar.
Residenzgebundene regionale Apps
Anwendungen, deren Verträge die Region benennen — bereitgestellt in dieser Region, in eurem Konto, nachweisbar.
Finanz- und Treasury-Workflows
Zahlungsnahe interne Tools, bei denen die erste Frage des Security-Teams ist, wo das läuft — beantwortet mit eurer VPC.
Betriebstools im Gesundheitswesen
Operative Workflow-Apps — Terminierung, Aufnahmekoordination, Dokumentations-Tracking — die innerhalb der eigenen Cloud-Grenze der Organisation laufen.
Workflows für öffentliche Dienstleistungen
Aufnahme- und Bearbeitungstools für den öffentlichen Sektor, bereitgestellt in staatlich kontrollierten Cloud-Konten unter den geforderten Bedingungen.
Anforderungen und wie Ciao sie abdeckt
Private-Cloud-Anforderungen kommen gleichzeitig von Plattform-, Security- und Beschaffungsteams und sind naturgemäß nicht verhandelbar. Diese Tabelle ordnet die Anforderungen, die in fast jedem Review auftauchen, der Art zu, wie die Plattform sie erfüllt — von der Kontokontrolle bis zu dem, was nach dem Launch passiert.
| Anforderung | Wie Ciao sie abdeckt |
|---|---|
| Läuft in unserem Konto | Deployment in euer eigenes AWS-, Azure- oder GCP-Konto oder eine private VPC |
| Region und Residenz | Multi-Region-Unterstützung und Data-Residency-Optionen |
| Unser Identity-Provider | SSO via SAML und OIDC, optionale MFA, RBAC |
| Audit-Nachweis | Unveränderlicher Trail über Prompts, Merges, Deployments, administrative Aktionen |
| Beschaffungs-Prüfung | SOC 2 Type II unter NDA; Zero-Retention-Modellverträge |
| Betrieb nach dem Launch | Doctor-Diagnose, SysOps-Drift-Erkennung und Rollback |
| Build-Tempo erhalten | Derselbe Builder in einfacher Sprache und Delivery-Loop wie die Ciao-Cloud |
Häufig gestellte Fragen
Welche Clouds werden unterstützt?
Deployment-Ziele umfassen euer eigenes AWS-, Azure- oder GCP-Konto und private VPC, neben der Ciao-Cloud und On-Prem. Private-VPC- und On-Prem-Deployments laufen unter separaten, mit dem Vertrieb eingegrenzten Bedingungen.
Was bedeutet Deployment unter separaten Bedingungen?
Private-VPC- und On-Prem-Deployments beinhalten Verpflichtungen über das Standard-Self-Service-Hosting hinaus — Umgebungsspezifika, Verantwortlichkeiten und Support-Grenzen —, daher werden sie separat vertraglich vereinbart. Ein Vertriebsgespräch definiert diese Bedingungen für eure Umgebung.
Wer kontrolliert die Infrastruktur nach dem Deployment?
Ihr — es ist euer Cloud-Konto, eure Netzwerkgrenze, eure Schlüssel und eure Region. Ciaos operatives Tooling arbeitet damit: Doctor ist nur lesend, wenn es die Live-App diagnostiziert, und SysOps übernimmt Drift, Rollback und Abgleich innerhalb des vereinbarten Setups.
Legt das Bauen auf der Plattform unsere Daten oder unseren Code offen?
Kundencode wird nie zum Training von Modellen verwendet, und Inferenz läuft unter Zero-Retention-Modellverträgen. SOC 2 Type II Berichte sind unter NDA verfügbar, und der unveränderliche Audit-Trail deckt Prompts, Merges, Deployments und administrative Aktionen für euer eigenes Review ab.
Unterscheidet sich die Bau-Erfahrung, wenn privat bereitgestellt wird?
Nein. Teams nutzen denselben Builder, dieselbe Live-Vorschau, denselben QA-, Security- und Guardrails-Loop wie auf der Ciao-Cloud. Der Unterschied ist das Ziel: Die ausgelieferte Anwendung landet in eurem Konto statt in unserem.
Wie wird das bepreist?
Private-Cloud-Programme sind Enterprise-Engagements: Entwicklungsprogramme starten bei 10.000 USD pro Jahr, mit separat eingegrenzten VPC-Deployment-Bedingungen. Sprecht mit dem Vertrieb mit eurem Zielkonto und eurer Region für eine konkrete Antwort.