Zum Inhalt springen

Microsoft Foundry · Azure AI

Individuell entwickeln, wenn die Anforderung es verlangt.

Nutzen Sie zusätzliche KI-Entwicklung dort, wo einfachere Microsoft-Funktionen oder Low-Code nicht ausreichen.

Wer beteiligt sein sollte: Technische Leitung, Entwicklungsteams sowie Plattform- und Produktverantwortliche

Wann lohnt sich individuelle KI-Entwicklung mit Microsoft Foundry?

Individuelle KI-Entwicklung mit Microsoft Foundry lohnt sich, wenn einfachere Lösungen eine wesentliche Anforderung nicht ausreichend erfüllen und der erwartete Nutzen die zusätzliche Betriebsverantwortung rechtfertigt. Die Lücke kann etwa Integration, Informationsabruf oder Anwendungsverhalten betreffen. Amplified Pi bewertet die vollständige Aufgabe einschließlich Quellen, Werkzeugen und menschlicher Prüfung. Ein stärkeres Modell oder ein beeindruckender Prototyp ist für sich genommen noch kein Investitionsargument.

Wann dieser Baustein passt
Für einen sinnvollen Anwendungsfall ist eine konkrete Funktionslücke belegt. Fachliche Prüfer und ein Plattformverantwortlicher können die spätere Anwendung begleiten.
Vor der Investition klären
Beschreiben Sie die fehlende Fähigkeit und vergleichen Sie vorhandene oder Low-Code-Lösungen. Klären Sie Qualität, Betreuung und Kosten, bevor individuelle Entwicklung zum nächsten Schritt wird.

Mehr Entwicklung nur für eine konkrete Anforderung.

Welche Anforderung bleibt mit einfacheren Mitteln unerfüllt?

Integration Modellwahl Wissensabruf Bewertung Betrieb

Einfachere Lösung erfüllt die Anforderung

Bei vorhandenen Funktionen oder Low-Code bleiben.

Eine relevante Lücke bleibt bestehen

Individuelle Entwicklung mit Microsoft Foundry prüfen.

Bei individueller Entwicklung klären:
Evaluation Identitäten und Daten Überwachung Kosten Wartung

Entscheidend sind die konkrete Lücke, der erwartete Nutzen und die Tragfähigkeit des Betriebs. Individuelle Entwicklung ist kein Selbstzweck.

Woran wir arbeiten

  • Die konkrete Lücke benennen, etwa bei Modellen, Wissensabruf, Integration oder Bewertung.
  • Grenzen für Identitäten, Netzwerk, Daten und Modelle entwerfen und einen abgegrenzten technischen Ansatz prüfen.
  • Den vereinbarten Baustein mit Evaluation, Überwachung, Kostenkontrolle und Betriebsübergabe umsetzen.

Was Sie erhalten

  • Eine Architekturentscheidung mit Vergleich zu einfacheren Optionen.
  • Eine abgegrenzte Implementierung mit Prüfdaten, Ergebnissen und Abhängigkeitsverzeichnis.
  • Ein Betriebsmodell für Störungen, Modellwechsel, Kosten und Stilllegung.

So gestalten wir die Umsetzung

Individuelle KI-Entwicklung soll eine konkrete Grenze einfacherer Lösungen überwinden. Wir machen diese Grenze überprüfbar und bauen den kleinsten sinnvollen Baustein mit den nötigen Prüf- und Betriebsverfahren.

  1. Die technische Lücke belegen

    Eine repräsentative Aufgabe wird mit dem bestehenden oder dem Low-Code-Ansatz verglichen. Die Lücke kann bei Integration, Wissensabruf, Modellverhalten oder Bewertung liegen. Wir vereinbaren, welche Verbesserung individuelle Entwicklung rechtfertigt und was außerhalb des ersten Bausteins bleibt.

    Ihr Ergebnis

    Eine Architekturentscheidung und eine abgegrenzte technische Hypothese.

  2. Daten- und Aktionsgrenzen entwerfen

    Wir erfassen Speicherung, Abruf und Übertragung von Daten, ausführende Identitäten und erforderliche Freigaben. Netzwerkzugang, Rechte, regionale Optionen und Dienstabhängigkeiten werden mit den Plattformverantwortlichen geprüft. Ungeklärte Vertrags- und Verarbeitungsannahmen bleiben sichtbar.

    Ihr Ergebnis

    Eine geprüfte Architektur und ein Abhängigkeitsverzeichnis.

  3. Vor der Optimierung einen Prüfkatalog aufbauen

    Fachliche Prüfer liefern typische Aufgaben, schwierige Fälle und unzulässige Ergebnisse. Bewertet wird die gesamte Anwendung einschließlich Wissensabruf und Werkzeugen. Ein öffentlicher Modellvergleich reicht dafür nicht. Änderungen werden gegen dieselbe Ausgangsbasis geprüft; automatische Bewertungen werden bei Bedarf fachlich ergänzt.

    Ihr Ergebnis

    Repräsentative Prüfdaten und eine dokumentierte Qualitätsentscheidung.

  4. Den Dienst betreibbar machen

    Wir legen aussagekräftige Alarme, Störungsverantwortung, Ersatzverfahren und einen Freigabe- beziehungsweise Rücksetzweg fest. Betrachtet werden Antwortzeiten, fehlgeschlagene Aufgaben, Qualitätsstichproben und Kosten je brauchbarem Ergebnis. Protokolle und Traces erhalten Zweck, Zugriffsregeln und Aufbewahrungsgrenzen, da sie sensible Inhalte enthalten können.

    Ihr Ergebnis

    Eine Betriebsanleitung und Nachweise für eine kontrollierte Freigabe.

Die fachliche Grundlage

Entwicklung mit ausdrücklichen Kontrollen

Microsoft Foundry verbindet Modell- und Agentenentwicklung mit Funktionen für Identität, Zugriff und Governance. Dass eine Plattform eine Kontrolle anbietet, ist eine Grundlage für die Planung, aber noch kein Nachweis für die Absicherung einer konkreten Anwendung.

Grundlage: Microsoft: Foundry overview

Bewertung endet nicht mit der Freigabe

Microsoft verbindet in seinen Observability-Hinweisen Evaluation, Überwachung und Tracing über den KI-Lebenszyklus. Wir unterscheiden damit Freigabetests, betriebliche Alarme und die Untersuchung eines einzelnen fehlgeschlagenen Vorgangs.

Grundlage: Microsoft: Foundry observability and evaluation

Illustratives Beispiel

Beispiel: Antworten aus mehreren geregelten Quellen

Ein Serviceteam benötigt eine Antwort aus freigegebenem Produktwissen und einem Datensatz aus einem weiteren System. Zuerst prüfen wir einfachere Werkzeuge. Ist individueller Wissensabruf begründet, untersucht der Versuch Quellenrelevanz, Berechtigungen und widersprüchliche Angaben gemeinsam. Eine flüssige Antwort mit falscher Quelle gilt als Fehler.

Was wir für den Einstieg brauchen

  • Produktverantwortliche und fachliche Prüfer
  • Freigegebene Prüfbeispiele und Schnittstellenzugang
  • Plattformverantwortung für Betrieb, Budget und Datenverarbeitung

Fragen vor dem Einstieg

Müssen wir ein eigenes Modell trainieren?

Nicht zwangsläufig. Zuerst prüfen wir Aufgabenbeschreibung, Quellenqualität, Wissensabruf und Integration. Ein Modellwechsel oder Training soll eine belegte Lücke schließen und den zusätzlichen Aufwand rechtfertigen.

Ist ein erfolgreicher Prototyp produktionsreif?

Ein Prototyp kann technische Machbarkeit belegen. Für den Betrieb braucht es zusätzlich akzeptierte Qualität, Zugriffskontrollen, Betreuung, Überwachung, Wiederherstellung und einen Kostenrahmen. Diese Arbeit wird vor der Freigabe sichtbar gemacht.

Passende weitere Bausteine

Die Entscheidung am Ende

Technische und fachliche Verantwortliche akzeptieren Qualitätsnachweise, Betriebsaufwand und Kostenrahmen.

Woran wir Fortschritt erkennen

Aufgabenbezogene Qualität, Antwortzeiten, Zuverlässigkeit und Kosten je Vorgang anhand vereinbarter Ziele prüfen.

Leistungsgrenze

Microsoft Foundry ist hier die aktuelle Produktbezeichnung für den Azure-AI-Pfad. Modelle, Regionen, Funktionsstatus und Datenverarbeitung sind im Einzelfall zu prüfen.

Der nächste Schritt ergibt sich aus den Ergebnissen.

Welche Arbeit folgt, hängt von den erkannten Voraussetzungen und Hindernissen ab. Nicht jedes Vorhaben benötigt alle Module.

Weitere Bausteine ansehen

Produkt- und Fachquellen

  • Microsoft Foundry overview
  • Microsoft: Foundry overview
  • Microsoft: Foundry observability and evaluation

Nächster Schritt