Databricks Artificial Intelligence: Wie AI vom Pilot in den Betrieb kommt
Die Kernaussagen auf einen Blick.
- Produktive AI auf Databricks entsteht erst, wenn Daten, Modelle, Anwendungen, Betrieb und Governance zusammenspielen.
- Ein gutes Modell ist nur ein Teil der Lösung. Entscheidend sind verlässliche Daten, klare Zugriffe, messbare Qualität, nachvollziehbare Versionen und kontrollierbare Kosten.
- Unternehmen können AI selbst bauen, fertige SaaS-Lösungen nutzen oder Databricks als gemeinsame AI-Plattform einsetzen. In der Praxis ist meist eine Kombination sinnvoll.
- Neue AI-Piloten sollten nicht jedes Mal eigene Modellzugänge, Logs, Berechtigungen und Betriebsprozesse mitbringen. Gemeinsame Schnittstellen, zentrale Protokollierung und klare Verantwortliche reduzieren spätere Umbauten.
Inhaltsverzeichnis
Zehn AI-Piloten sind noch keine Plattform
In vielen Unternehmen starten AI-Projekte zunächst unabhängig voneinander.
Ein Fachbereich testet einen Assistenten für interne Dokumente. Ein anderes Team möchte Informationen automatisch aus Dokumenten auslesen. Der Vertrieb testet parallel Empfehlungen, Zusammenfassungen oder automatisch erstellte Texte.
Für erste Tests wählen Teams häufig unterschiedliche Werkzeuge und Anbieter: einen direkten Modellanbieter-Zugang, ein Modell über einen Cloud-Anbieter, ein selbst betriebenes freies Modell, verschiedene Suchsysteme für Dokumente und eigene Entwicklungs- und Protokollierungslösungen.
Für kleine Piloten wirkt diese Vielfalt zunächst unkritisch. Sobald Anwendungen produktiv werden, müssen jedoch dieselben grundlegenden Fragen beantwortet werden:
- Welche Daten werden an welchen Modellanbieter übertragen?
- Welches Modell und welche Version haben eine Antwort erzeugt?
- Welche Kosten entstehen pro Anwendung, Nutzer oder bearbeitetem Vorgang?
- Wo werden Prompts, Qualitätstests und Freigaben nachvollziehbar gespeichert?
- Wie werden personenbezogene oder vertrauliche Inhalte geschützt?
- Wer ist fachlich und technisch für die Anwendung verantwortlich?
- Wie kann ein Modell ausgetauscht werden, ohne alle Anwendungen technisch anzupassen?
Wenn jedes Team diese Fragen selbst löst, entstehen unterschiedliche Schnittstellen, Sicherheitsmodelle, Logs und Betriebsprozesse. Dadurch steigen Kosten und Betriebsaufwand. Sicherheitsprüfungen und spätere Änderungen werden schwieriger.
Eine gemeinsame AI-Plattform bedeutet nicht, dass alle Anwendungen gleich gebaut werden. Ein Wissensassistent hat andere Anforderungen als eine Dokumentenextraktion oder ein Empfehlungssystem.
Gemeinsam geregelt werden sollten die wiederkehrenden Grundlagen fast jeder AI-Anwendung: Modellzugriff, Berechtigungen, Logging, Kostenkontrolle, Evaluation, Versionierung, Bereitstellung und Monitoring.
Hier kann Databricks eine gemeinsame technische Grundlage liefern. Diese Pillar Page ordnet die Plattform in vier Bereiche ein: Daten, Modelle, Anwendungen sowie Betrieb und Governance.
Was ist Databricks Artificial Intelligence?
AI auf Databricks ist keine einzelne Funktion.
Unter Mosaic AI bündelt Databricks zentrale Funktionen für Machine Learning, Generative AI und Agenten. Damit lassen sich klassische ML-Modelle, generative AI und mehrstufige AI-Anwendungen entwickeln, bereitstellen und überwachen.
Dazu gehören unter anderem:
- Zugriff auf Sprach- und Embedding-Modelle,
- Training und Fine-Tuning eigener Modelle,
- Suche in eigenen Daten und Dokumenten,
- Entwicklung von Agenten,
- Dokumentation von Experimenten und verwendeten Prompts,
- Modellregistrierung,
- Bereitstellung von Modellen über zentrale Schnittstellen,
- Monitoring und Governance.
Databricks liegt damit zwischen vollständigem Eigenbau und fertiger SaaS-Anwendung:
Eigenbau
Maximale Freiheit, aber hoher Integrations- und Betriebsaufwand.
SaaS
Schneller Einstieg, aber zusätzliche Anbieter-, Datenschutz- und Integrationsfragen.
Databricks
Gemeinsame Daten, Governance und Modellbereitstellung, aber stärkere Plattformbindung.
Die Vor- und Nachteile vertiefen wir weiter unten im Abschnitt zu Databricks, Eigenbau und SaaS.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Die vier Bausteine für produktive AI auf Databricks
Für die Architekturplanung lässt sich Databricks AI in vier Bereiche gliedern.
| Bereich | Zentrale Frage | Typische Komponenten | Ziel |
|---|---|---|---|
| Daten | Auf welche Daten darf die Anwendung zugreifen? | Unity Catalog, Feature Store, Lakebase, Lineage | Verlässliche Daten mit klaren Zugriffsrechten |
| Modelle | Welche Modelle werden verwendet und über welche Schnittstelle? | Foundation Model APIs, External Models, Unity AI Gateway, Model Serving | Einheitlicher und nachvollziehbarer Zugriff auf Modelle |
| Anwendung | Wie werden Modelle, Daten und Geschäftsprozesse zu einer Anwendung verbunden? | AI Search, RAG, Agent Bricks, AI Functions | Assistenten, Dokumentenverarbeitung und automatisierte Abläufe |
| Betrieb und Governance | Wie werden Qualität, Änderungen, Freigaben und Betrieb kontrolliert? | MLflow, Model Registry, Monitoring, Evaluation | Nachvollziehbare und dauerhaft überwachte AI-Anwendungen |
Keiner dieser Bereiche reicht allein für produktive AI aus.
Ein Wissensassistent benötigt gepflegte Daten, Suche, Modellzugriff, Tests, Monitoring und klare Berechtigungen. Eine Agenten-Anwendung, die weitere Systeme aufruft, benötigt zusätzlich kontrollierte Zugriffe und klare Verantwortliche.
Für den Aufbau ist diese Reihenfolge sinnvoll:
Datenzugriff klären
Berechtigungen für Daten und Modelle festlegen, bevor Anwendungen darauf zugreifen.
Gemeinsamen Modellzugriff einrichten
Eine zentrale Schnittstelle für alle Modelle aufbauen, statt pro Team eigene Zugänge.
Mit einem begrenzten Anwendungsfall starten
Ein klar abgegrenzter, messbarer Pilot statt einer vollständigen Plattform auf Vorrat.
Qualitätstests und Governance einplanen
Monitoring, Tests und Governance von Anfang an mitdenken, nicht erst kurz vor dem Go-live.
Betrieb und Governance sollten nicht erst kurz vor dem Go-live ergänzt werden. Sie gehören bereits in einen realistischen Pilot.
Unity Catalog, Feature Store und Lakebase
Die Qualität einer AI-Anwendung hängt stark von den Daten ab, auf die sie zugreift. Das gilt für Trainingsdaten, RAG, Feature Stores und produktive Modellaufrufe.
Korrekte Daten reichen allein nicht aus. Ebenso wichtig sind Zugriffsrechte, Aktualität, Herkunft, klare fachliche Definitionen, der Umgang mit personenbezogenen Inhalten, Aufbewahrungs- und Löschfristen sowie regionale, rechtliche und regulatorische Anforderungen.
Unity Catalog für Zugriffe und Nachvollziehbarkeit
Unity Catalog verwaltet Daten, Modelle und Plattformobjekte mit zentralen Berechtigungen, Beschreibungen und Lineage.
Für AI-Anwendungen ist dies besonders wichtig, wenn ein Assistent vertrauliche oder personenbezogene Daten verwenden kann.
Ein Nutzer darf über einen Assistenten nur Informationen erhalten, die er auch direkt in der Datenplattform sehen dürfte. Diese Zugriffsrechte müssen auch bei Suche, RAG und Modellantworten gelten.
Zusätzlich lässt sich nachvollziehen, woher Daten stammen und welche Anwendungen sie verwenden:
Herkunft
Welche Datenquelle wurde für ein Objekt genutzt?
Zugehörigkeit
Welche Tabellen, Dokumente und Suchindizes gehören zu einer Anwendung?
Zugriffsrechte
Wer darf auf das Objekt zugreifen?
Verantwortlichkeit
Welches Team verantwortet das Objekt?
Nutzung
Welche Modelle und Anwendungen greifen darauf zu?
Feature Store für wiederverwendbare Features
Der Feature Store verwaltet Features, die von mehreren ML-Modellen verwendet werden können.
Das hilft dabei, dieselben Features im Training und im späteren Betrieb zu verwenden. So lassen sich Unterschiede zwischen Training und produktiver Nutzung reduzieren. Wenn Feature-Frische in Sekunden statt Stunden relevant ist, etwa bei Live-Scoring oder Echtzeit-Empfehlungen, klären wir im Überblick zu Real-Time Machine Learning auf Databricks.
Auch generative AI kann mit klassischen Kundendaten, Segmenten oder historischen Ereignissen kombiniert werden. Ein Empfehlungssystem kann beispielsweise Produkttexte und Embeddings mit Vertragsmerkmalen und früheren Interaktionen verbinden.
Lakebase für App-Zustand und schnelle Schreibvorgänge
Interaktive AI-Anwendungen benötigen neben analytischen Daten oft auch schnell veränderbare operative Daten:
Sitzungszustände
Benutzereinstellungen und aktuelle Sitzungszustände.
Konversationen
Verlauf und Kontext laufender Dialoge.
Feedback
Rückmeldungen von Nutzern zur Anwendung.
Anwendungseinstellungen
Aktuelle Konfiguration der laufenden Anwendung.
Live-Merkmale
Merkmale, die während einer Anfrage sofort verfügbar sein müssen.
Bearbeitungsstatus
Freigaben und Zwischenergebnisse laufender Vorgänge.
Lakebase kann solche transaktionalen Daten ergänzend zum Lakehouse speichern. Damit lassen sich operative Zustände speichern, ohne das Lakehouse zu ersetzen.
Für jede Anwendung muss geklärt werden, welche Daten sie in welcher Situation benötigt und wie sich dieser Zugriff später nachvollziehen lässt.
Foundation Model APIs, External Models, Gateway und Model Serving
AI-Anwendungen verwenden je nach Aufgabe unterschiedliche Modelle: Sprach- und Embedding-Modelle, Klassifikationsmodelle, eigene Machine-Learning-Modelle und speziell angepasste offene Modelle.
Ohne gemeinsame Schnittstelle bindet jedes Team Modelle direkt in die eigene Anwendung ein. So entstehen unterschiedliche Zugangsdaten, Bibliotheken, Logs, Sicherheitsregeln und Abrechnungswege.
Der fachliche Rahmen dafür sind Generative AI auf Databricks und die Auswahl geeigneter Large Language Models, darunter externe proprietäre Modelle sowie Open-Weight-Modelle wie Llama 4 oder Mistral. Für die Auswahl zählen Anwendungsfall, Sprache, Datenschutz, Qualität, Latenz und Kosten.
Foundation Model APIs
Über Foundation Model APIs lassen sich ausgewählte Modelle direkt über Databricks-Schnittstellen nutzen.
Dadurch müssen Teams keine eigene Modellinfrastruktur betreiben. Verfügbarkeit, Kosten, Region und Skalierung müssen trotzdem pro Anwendung geprüft werden.
Externe Modelle
Auch externe Anbieter können über eine einheitliche Databricks-Schnittstelle eingebunden werden.
Anwendungen müssen dadurch nicht jede Anbieterlogik selbst implementieren. Zugangsdaten, Freigaben und Protokollierung lassen sich stärker bündeln.
Verträge, Datenschutz und Kosten des externen Anbieters bleiben trotzdem relevant.
Eigene Modelle und Model Serving
Eigene oder speziell angepasste Modelle lassen sich über MLflow zentral versionieren und über Model Serving für Anwendungen verfügbar machen.
Das eignet sich unter anderem für:
Klassische ML-Modelle
Traditionelle Machine-Learning-Modelle für Klassifikation, Regression und Scoring.
Spezialisierte Klassifikatoren
Modelle für eng abgegrenzte Klassifikationsaufgaben.
Eigene Embedding-Modelle
Selbst trainierte oder angepasste Embedding-Modelle.
Angepasste offene Modelle
Speziell angepasste Open-Weight-Modelle für den eigenen Anwendungsfall.
Unity AI Gateway für zentrale Regeln, Routing und Kostenkontrolle
Das Unity AI Gateway kann als gemeinsame Zugangsschicht vor verschiedenen Modellen dienen.
Je nach Setup können dazu gehören: Auswertungen zu Nutzung und Kosten, Limits für Anzahl und Häufigkeit von Anfragen, Protokollierung, Regeln und Filter für Eingaben, Ausgaben und sensible Inhalte sowie die Weiterleitung an unterschiedliche Modelle oder Endpunkte.
Diese Regeln müssen dadurch nicht in jeder einzelnen Anwendung erneut entwickelt werden.
Ein gemeinsamer Zugang erleichtert Modellwechsel, ersetzt aber keine erneuten Qualitäts- und Sicherheitstests. Vor einem Wechsel müssen weiterhin Antwortqualität, externe Aktionen, Latenz, Kosten und Schutzverhalten getestet werden.
Ein einziges Standardmodell für alle Anwendungsfälle ist selten sinnvoll. Unterschiedliche Anwendungsfälle können unterschiedliche Modelle benötigen.
RAG, AI Search, Agent Bricks und AI Functions
Eine Modellschnittstelle allein schafft noch keinen Nutzen für den Fachbereich.
Erst die Verbindung mit Unternehmensdaten, Prozessen und Nutzeroberflächen macht daraus eine Anwendung:
Wissensassistenten
Assistenten, die Fragen zu internen Dokumenten beantworten.
Dokumentenextraktion
Automatisches Auslesen von Informationen aus Dokumenten.
Ticketklassifikation
Automatische Einordnung eingehender Anfragen und Tickets.
Empfehlungen
Automatisch erzeugte Produkt- oder Inhaltsvorschläge.
Mehrstufige Recherche-Assistenten
Assistenten, die mehrere Rechercheschritte selbstständig ausführen.
Automatisierte Abläufe
Prozesse über mehrere Arbeitsschritte hinweg automatisiert.
AI Search und RAG
AI Search kombiniert klassische Suche mit semantischer Ähnlichkeitssuche auf ausgewählten Unternehmensdaten.
Bei RAG sucht das System zuerst passende Inhalte in freigegebenen Dokumenten oder Datenquellen. Diese Inhalte werden anschließend gemeinsam mit der Frage an das Sprachmodell übergeben.
Suche vor der Antwort: so verbindet RAG Dokumente und Sprachmodell..
Freigegebene Dokumente werden durchsucht, die Treffer landen zusammen mit der Frage beim Sprachmodell.
Delta Lake
ParquetDie Qualität hängt von mehreren Faktoren ab:
- Auswahl der Quelldokumente,
- Bereinigung der Inhalte,
- sinnvolle Aufteilung der Dokumente,
- Metadaten,
- Embedding-Modell,
- Filter und Berechtigungen,
- zusätzliche Sortierung der Suchtreffer,
- Prompt,
- Antwortmodell,
- systematische Tests.
Databricks kann viele technische Grundlagen für Suche, Bereitstellung und Governance bereitstellen. Die Qualität von Quellen, Suche und Antworten muss trotzdem systematisch geprüft werden. Das AI Playground eignet sich für frühe Modell- und Prompt-Tests, ersetzt aber keine systematische Evaluation.
Agent Bricks für typische AI-Anwendungen
Agent Bricks bietet vorbereitete Bausteine für typische Anwendungen wie Wissensassistenten, Informationsextraktion oder das Zusammenspiel mehrerer spezialisierter AI-Bausteine.
Dadurch müssen Teams weniger technische Grundlagen selbst bauen. Dazu können Datenanbindung, Qualitätstests und Bereitstellung gehören. Bei komplexen, stark individuellen Prozessen kann jedoch ein eigenes Framework sinnvoller sein.
Agent Bricks wählen, wenn
- Der Anwendungsfall zu typischen Mustern wie Wissensassistenten oder Informationsextraktion passt
- Mehrere spezialisierte AI-Bausteine zusammenspielen sollen
- Datenanbindung, Qualitätstests und Bereitstellung nicht komplett selbst gebaut werden sollen
Eigenes Framework wählen, wenn
- Die Anwendung viele Bearbeitungszustände speichern muss
- Viele externe Systeme angebunden sind
- Individuelle Freigabeschritte existieren
- Ein Vorgang über längere Zeit und mehrere Systeme läuft
- Fehler gezielt behandelt und abgebrochene Vorgänge fortgesetzt werden müssen
AI Functions für AI direkt in SQL und Datenprozessen
AI Functions ermöglichen es, Modelle direkt aus SQL und Pipelines aufzurufen.
Das eignet sich beispielsweise für die Klassifikation von Freitext, Informationsextraktion, Übersetzung, Zusammenfassung oder die Ergänzung bestehender Datensätze um automatisch erzeugte Informationen.
Bei großen Datenmengen müssen Kosten, Laufzeit und Wiederholbarkeit besonders sorgfältig betrachtet werden. Modellaufrufe pro Tabellenzeile können schon bei mittleren Datenmengen hohe Kosten erzeugen.
Damit lassen sich AI-Funktionen direkt mit Business-Intelligence-Anwendungen auf derselben Datenbasis verbinden.
Vom Experiment zum Betrieb
Eine produktive AI-Anwendung braucht Dokumentation, Tests, Freigabe, Monitoring und klare Verantwortliche.
Ein Notebook-Test und eine funktionierende Modellschnittstelle reichen dafür nicht aus.
Experimente, Prompts und Modellversionen mit MLflow dokumentieren
Managed MLflow kann unter anderem folgende Informationen dokumentieren:
- verwendete Daten, Einstellungen und Modellparameter,
- Modellversion,
- Prompt-Version,
- Qualitätsmetriken,
- Artefakte,
- Laufzeit und Kosten,
- zugehöriges Projekt und verantwortliches Team.
So lässt sich später nachvollziehen, warum eine Version besser, schlechter oder teurer war. Die Verbindung zur Data-Engineering-Schicht hilft dabei, dieselben Datenprozesse für Entwicklung und produktiven Betrieb zu verwenden.
Modellversionen zentral verwalten
Die Mosaic AI Model Registry verwaltet freigegebene Modellversionen mit eindeutiger Version, Verantwortlichem und Freigabestatus.
Eine Registrierung kann beispielsweise dokumentieren:
- technische Version,
- fachlich und technisch verantwortliche Personen,
- Herkunft,
- Qualitätsergebnisse,
- Berechtigungen,
- Freigabestatus,
- freigegebene Einsatzbereiche und bekannte Einschränkungen.
Ein registriertes Modell ist noch nicht automatisch produktionsreif. Die Registry schafft aber die Grundlage für kontrollierte Freigaben, Rollbacks und spätere Änderungen. Für die Automatisierung wiederkehrender MLOps-Aufgaben wie Re-Training, Promotion oder Reaktion auf Monitoring-Signale zeigen wir den Überblick zu ML Engineering Agents auf Databricks.
Eigenes Training nur bei klar messbarem Bedarf einsetzen
Nach einem ersten Modelltest sollte nicht automatisch eigenes Training folgen.
Zunächst sollte geprüft werden, ob das Problem durch folgende Maßnahmen gelöst werden kann:
Bessere Daten
Datenqualität verbessern, bevor eigenes Training in Betracht kommt.
Klarere Prompts
Prompt-Formulierung optimieren.
Bessere Dokumentensuche
Qualität der Suche und Trefferauswahl verbessern.
Kontrollierter Systemzugriff
Zugriff auf weitere Systeme und Funktionen gezielt freigeben.
Vorgegebene Antwortformate
Klar strukturierte Antwortformate erzwingen.
Geeigneteres Basismodell
Ein passenderes Basismodell auswählen.
Mosaic AI Training kann sinnvoll sein, wenn für einen wiederkehrenden Anwendungsfall eine konkrete und messbare Verbesserung gegenüber der bisherigen Lösung erwartet wird. Für strukturierte Klassifikations-, Regressions- und Forecasting-Aufgaben deckt AutoML viele Standardpfade ab.
Das Training eines eigenen großen Sprachmodells ist für die meisten Unternehmen nur bei sehr speziellen Anforderungen sinnvoll.
Model Serving für Anwendungen
Model Serving stellt Modelle über zentrale Schnittstellen für Anwendungen bereit.
Für die produktive Nutzung müssen zusätzlich Fragen geklärt werden:
- Welche Latenz wird benötigt?
- Wie viele gleichzeitige Anfragen muss das Modell verarbeiten können?
- Wie werden Fehler behandelt?
- Welche Modellversion ist aktuell freigegeben?
- Wie kann bei Problemen schnell auf eine frühere Version zurückgewechselt werden?
- Welche Anfragen, Antworten und technischen Daten werden protokolliert?
- Welche Anwendung darf den Endpoint aufrufen?
Für einen belastbaren Betrieb braucht es mindestens:
Versionierte Komponenten
Alle Bausteine sind eindeutig versioniert.
Klare Verantwortliche
Technische und fachliche Verantwortliche sind benannt.
Versionierte Schnittstelle
Eine klar beschriebene und versionierte Schnittstelle.
Definierte Qualitätskriterien
Messbare Kriterien für ausreichende Qualität.
Monitoring
Laufende Überwachung im Betrieb.
Geregelter Update-Prozess
Klarer Prozess für Updates, Rücknahme und Abschaltung.
Qualität, Sicherheit, Kosten und Verantwortung
Mit dem Go-live beginnt die eigentliche Betriebsverantwortung.
Antwortqualität, Verhalten, Nutzung und Kosten können sich im Betrieb verändern, wenn:
- neue Datenquellen hinzukommen,
- Eingabedaten andere Muster aufweisen,
- Nutzer andere Fragen stellen,
- Prompts angepasst werden,
- ein Modellanbieter eine neue Version bereitstellt,
- Dokumente und Suchindizes aktualisiert werden,
- externe Systeme verändert werden.
Qualität und Nutzung regelmäßig messen
Lakehouse Monitoring kann Veränderungen in Daten, Modellantworten und Nutzung auswerten.
Je nach Anwendungsfall gehören dazu technische Kennzahlen:
Veränderungen in Eingabedaten
Verschiebungen in Menge, Muster oder Herkunft der Eingaben.
Veränderungen in Antworten
Abweichungen in erzeugten Antworten oder Klassifikationen.
Fehlerraten
Anteil fehlgeschlagener oder abgebrochener Anfragen.
Antwortzeiten
Latenz zwischen Anfrage und Antwort.
Bei generativer AI reichen technische Kennzahlen allein meist nicht aus. Zusätzlich müssen Antworten fachlich, automatisiert oder stichprobenartig geprüft werden, etwa auf Korrektheit, Relevanz, Übereinstimmung mit den verwendeten Quellen sowie falsche, unsichere oder unzulässige Antworten. Dazu gehören auch Nutzungs- und Qualitätssignale:
Nutzung
Wie stark und von wem die Anwendung verwendet wird.
Kosten
Modell-, Infrastruktur- und Betriebskosten je Anwendungsfall.
Fachliche Kriterien
Messbare Kriterien für richtige und hilfreiche Antworten.
Nutzerfeedback
Rückmeldungen aus dem laufenden Betrieb.
Kontrollen an das Risiko der Anwendung anpassen
Ein interner Assistent braucht andere Kontrollen als eine Anwendung, deren Ergebnisse finanzielle, rechtliche oder regulatorische Folgen haben.
Je nach Anwendung können folgende Kontrollen notwendig sein:
- klar beschriebener Anwendungszweck und erlaubte Nutzung,
- Risikobewertung,
- Datenfreigabe,
- Modell- und Prompt-Versionierung,
- verbindliche Prüfung durch einen Menschen bei kritischen Entscheidungen,
- Audit-Logs,
- Qualitätsgrenzen,
- Freigabeprozess,
- geregelter Umgang mit falschen oder schädlichen Ergebnissen,
- Möglichkeit, die Anwendung oder einzelne Funktionen schnell zu deaktivieren.
AI Governance auf Databricks stellt dafür technische Bausteine bereit. Databricks unterstützt die technische Umsetzung. Rechtliche und fachliche Verantwortung bleiben beim Unternehmen.
Ein kleiner Pilot kann mit vereinfachten Kontrollen starten. Je später Regeln für Daten, Logs, Berechtigungen und Freigaben festgelegt werden, desto größer wird der spätere Umbau für einen produktiven Betrieb.
Welcher Ansatz passt wann?
Für AI-Anwendungen gibt es drei Grundwege. Eigenbau bedeutet maximale Freiheit, aber auch maximale Verantwortung für Integration und Betrieb. SaaS eignet sich, wenn ein klarer Standardanwendungsfall schnell umgesetzt werden soll. Databricks eignet sich, wenn AI-Anwendungen eng mit der bestehenden Datenplattform, Governance und Modellbereitstellung verbunden werden sollen.
| Ansatz | Passend wenn | Vorteile | Risiken |
|---|---|---|---|
| Eigenbau | besondere technische Anforderungen, erfahrene Entwickler im Haus, geringe Bindung gewünscht | maximale Flexibilität, freie Komponentenwahl, individuelle Optimierung | hoher Integrations- und Betriebsaufwand, eigener Sicherheits- und Update-Betrieb, hoher Personalbedarf |
| SaaS | klar abgegrenzter Standardfall, schneller Einstieg, wenig Anpassbedarf | schneller Einstieg, fertige Oberfläche, wenig Entwicklung | Datenübertragung an weiteren Anbieter, eingeschränkte Anpassung, Lizenz- und Anbieterabhängigkeit |
| Databricks | mehrere AI-Anwendungen, gemeinsame Daten/Governance/Bereitstellung erwünscht | gemeinsame Daten und Zugriffsrechte, integriertes MLflow/Model Serving, zentrale Governance | stärkere Plattformbindung, Aufwand zur Einordnung vieler Komponenten, Spezialfälle teils nicht nativ abgedeckt |
In der Praxis ist meist eine Kombination sinnvoller als eine reine Entweder-oder-Entscheidung. Eine Standardanwendung kann als fertige Software eingekauft werden. Ein individueller Agent kann selbst entwickelt werden. Daten, Modelle, Bereitstellung und Governance können trotzdem zentral über Databricks geregelt werden.
Die Entscheidung sollte pro Anwendungsfall anhand weniger Kriterien getroffen werden:
- Sensibilität der Daten,
- Anpassungsbedarf,
- erwartete Nutzerzahl,
- Integrationsanforderungen,
- vorhandene Erfahrung im eigenen Team,
- Betriebsaufwand,
- Kosten,
- regulatorisches Risiko.
Drei Stufen vom Pilot zum geregelten Betrieb
Die meisten Unternehmen entwickeln ihren AI-Betrieb schrittweise.
Stufe 1: Unabhängige AI-Piloten
Einzelne Teams testen eigene Modelle, Anbieter und Anwendungen.
Typische Merkmale sind:
- direkte Anbieterzugänge,
- Experimente in Notebooks,
- keine gemeinsame Übersicht über Nutzung und Kosten,
- unterschiedliche Frameworks,
- Qualität wird nur anhand weniger Beispiele bewertet,
- unklare Verantwortlichkeiten,
- fehlende Audit- und Betriebsprozesse.
Ob eine Lösung funktioniert, wird vor allem anhand von Demos und wenigen Testfällen bewertet.
Stufe 2: Erste gemeinsame Standards
Wiederkehrende Aufgaben werden teilweise zentral geregelt.
Typische Merkmale sind:
- zentrale Modellendpoints,
- MLflow für Experimente,
- Unity Catalog für relevante Daten,
- mindestens eine produktive Wissens- oder ML-Anwendung,
- einheitliche Protokollierung und Veröffentlichungsprozesse,
- erste Regeln für Qualitätstests und Freigabe.
Bestehende Piloten und neue Anwendungen folgen aber noch nicht durchgehend denselben Regeln.
Stufe 3: Geregelter AI-Betrieb
Entwicklung, Freigabe, Betrieb und Abschaltung folgen verbindlichen Standards.
Typische Merkmale sind:
- kontrollierter Modellzugriff,
- zentrale Kosten- und Nutzungsinformationen,
- nachvollziehbare Versionen von Prompts, Modellen und verwendeten Daten,
- verbindliche Qualitätstests vor jeder produktiven Änderung,
- Monitoring im Betrieb,
- klare fachliche und technische Verantwortliche,
- dokumentierte Risikoklassen,
- nachvollziehbare Daten- und Modell-Lineage,
- geregelte Abläufe für Updates, Rücknahme und Stilllegung.
Klassisches Machine Learning und generative AI können dieselben Grundlagen für Daten, Versionierung und Bereitstellung verwenden. Ihre Qualitätsmessung und Risiken unterscheiden sich jedoch teilweise deutlich.
Der entscheidende Schritt liegt weniger in neuen Tools als in verbindlichen Regeln:
- Dürfen Anwendungen externe Modelle direkt ansprechen oder nur über eine zentrale Schnittstelle?
- Welche Experimente müssen in MLflow dokumentiert werden?
- Welche Tests müssen vor einer Freigabe bestanden werden?
- Welche Daten dürfen an externe Modelle gesendet werden?
- Wer darf neue Modell-, Prompt- oder Datenversionen produktiv freigeben?
- Wie werden Kosten einem Anwendungsfall zugeordnet?
Was Databricks AI nicht automatisch löst
Databricks kann Daten, Modelle, Bereitstellung und Governance bündeln. Fachliche Qualität, Wirtschaftlichkeit und Verantwortung bleiben trotzdem beim Unternehmen.
Modelle müssen real getestet werden
Databricks ersetzt keine Tests mit echten Daten, echten Nutzerfragen und echten Qualitätskriterien. Ein Modell kann bei einer Aufgabe gut und bei einer anderen deutlich schlechter sein.
Kosten sind mehr als Modellaufrufe
Wer nur Modellaufrufe betrachtet, unterschätzt häufig Entwicklung, Integration, Monitoring und Betrieb.
Plattformbindung gehört zur Entscheidung
Klare Schnittstellen und offene Standards können die Abhängigkeit reduzieren, eine stark integrierte Plattform bleibt aber nicht anbieterunabhängig.
Rechtliche Verantwortung bleibt beim Unternehmen
Databricks dokumentiert Nachweise, Versionen und Zugriffe technisch. Ob eine Anwendung rechtlich zulässig ist und welches Risiko sie trägt, muss das Unternehmen selbst bewerten.
Ohne saubere Datenplattform skaliert AI schlecht
Ein Pilot ist auch vorher möglich, sollte aber bereits grundlegende Regeln für Zugriffe, Protokolle und Modellversionen mitbringen.
Fazit
Produktive AI auf Databricks braucht mehr als ein gutes Modell oder eine überzeugende Demo.
Vier Bereiche müssen dauerhaft zusammenspielen: verlässliche Daten mit klaren Zugriffsrechten, gemeinsame und protokollierte Schnittstellen zu Modellen, eine klare Verbindung von Modellen, Daten und Geschäftsprozessen sowie Qualitätstests, Versionierung, Überwachung und klare Regeln.
Databricks bündelt dafür viele technische Funktionen auf einer gemeinsamen Datenplattform. Dazu gehören unter anderem Unity Catalog, MLflow, Model Serving, Unity AI Gateway, AI Search und Agent Bricks.
Das kann Entwicklung und Betrieb mehrerer AI-Anwendungen deutlich vereinfachen. Die fachlichen und organisatorischen Aufgaben bleiben trotzdem bestehen:
- geeignete Anwendungsfälle auswählen und priorisieren,
- Daten vorbereiten,
- Modelle testen,
- festlegen, wann eine Antwort oder Entscheidung als ausreichend gut gilt,
- Risiken bewerten,
- Verantwortlichkeiten festlegen.
Vor dem ersten produktiven Anwendungsfall sollte meist keine vollständige AI-Plattform auf Vorrat gebaut werden.
Der nächste Schritt sollte eine klare Bestandsaufnahme sein:
- Welche AI-Anwendungen werden bereits getestet, geplant oder produktiv genutzt?
- Welche Daten benötigen sie?
- Welche Modelle, Anbieter und direkten Zugänge existieren bereits?
- Welche Lösungen verursachen heute hohe Kosten, unklare Zugriffe oder zusätzlichen Betriebsaufwand?
- Welche Logs und Qualitätstests fehlen?
- Welche wiederkehrenden Funktionen sollten künftig für alle Teams gemeinsam angeboten werden?
Auf dieser Grundlage lässt sich priorisieren, ob zuerst ein zentraler Modellzugang, ein produktiver Wissensassistent, ein MLflow-Standard oder ein Governance-Prozess aufgebaut werden sollte.
Als nächste Vertiefung passen je nach Fokus unterschiedliche Cluster. Für den Modellzugang lohnt der Blick in Foundation Model APIs und das Unity AI Gateway. Für einen produktiven Wissensassistenten führen AI Search, Retrieval-Augmented Generation und Agent Bricks tiefer. Für den Betrieb spielen Managed MLflow, die Mosaic AI Model Registry, Model Serving, Lakehouse Monitoring und AI Governance zusammen.
Data & AI Assessment
In einem Data & AI Assessment bewerten wir eure bestehenden AI-Anwendungen, Modellzugänge und technischen Grundlagen. Als Ergebnis erhaltet ihr ein priorisiertes Zielbild und einen umsetzbaren Fahrplan vom Pilot zum geregelten produktiven Betrieb.
- welche eurer AI-Anwendungsfälle produktiv tragen und welche Daten, Berechtigungen und Modellzugänge sie brauchen
- ob gemeinsame Schnittstellen, eigene Endpoints oder fertige SaaS-Lösungen jeweils der passende Pfad sind
- wie Qualitätstests, Monitoring und Governance aufgebaut werden, damit aus dem Pilot ein geregelter Betrieb wird
FAQ
Mosaic AI bündelt die Funktionen für Machine Learning und generative AI innerhalb von Databricks. Dazu gehören Modellzugriff, Dokumentensuche, Agenten, Training, Bereitstellung, Qualitätstests und Governance. Bei der Planung sollten die benötigten Funktionen einzeln bewertet werden, statt Mosaic AI als eine einzige fertige Anwendung zu betrachten.
