Architektur und Governance für KI

In diesem Artikel wird erläutert, wie KI-Workloads in Ihre Azure Landing Zone und Unternehmensarchitektur passen. Es identifiziert die zusätzlichen Plattformfunktionen, die Organisationen mit zunehmender KI-Einführung berücksichtigen sollten.

Wenden Sie dieselben Azure-Landing-Zone-Prinzipien und bewährten Methoden auf KI-Workloads an, wie Sie es für andere Workloads tun. KI-Workloads erfordern keine andere Azure Landing Zone-Architektur oder kein anderes Governancemodell. Plattformteams sollten ihre vorhandene Governance-Basislinie verwenden und bei Bedarf erweitern, um die KI-Dienste und -Modelle zu berücksichtigen, die die Organisation zu verwenden plant.

Ergebnis: Am Ende der Architektur- und Governanceplanung sollten Sie über eine aktualisierte Governance-Basislinie verfügen, die die KI-Technologien unterstützt, die Sie in Azure verwenden möchten.

Architekturen und Entscheidungsbaum

Konzeptionell

Diagramm einer Schichtenarchitektur. Ein oberstes Banner mit der Bezeichnung "Einheitliche Identität, Sicherheit und Governance" enthält Microsoft Agent 365, Microsoft Defender, Microsoft Entra und Microsoft Purview. Darunter enthält ein großes Azure-Landing-Zone-Kästchen eine Plattform-Landing-Zone, die zentriert über einem Abschnitt mit den Workload-Landing-Zones angeordnet ist. Der Abschnitt „Workload-Landingzones“ enthält drei Kästen für Workload-Landingzones, die Azure-Workloads darstellen. Unterhalb der Workloads ist ein Feld für Microsoft Foundry und Foundry IQ durch gestrichelte Pfeile mit den Workload-Landingzones verbunden, wodurch optionale KI-Funktionen für ausgewählte Workloads angezeigt werden.

KI in einer Azure-Landingzone. Laden Sie eine PowerPoint Datei dieser Architektur herunter.

Konzeption und Integration

Diagramm einer Schichtenarchitektur. Ein oberstes Banner mit der Bezeichnung "Einheitliche Identität, Sicherheit und Governance" enthält Microsoft Agent 365, Microsoft Defender, Microsoft Entra und Microsoft Purview. Darunter enthält ein großes Azure-Landing-Zone-Kästchen eine Plattform-Landing-Zone, die zentriert über einem Abschnitt mit den Workload-Landing-Zones angeordnet ist. Der Abschnitt „Workload-Landingzones“ enthält drei Kästen für Workload-Landingzones, die Azure-Workloads darstellen. Unterhalb der Workloads ist ein Feld für Microsoft Foundry und Foundry IQ durch gestrichelte Pfeile mit den Workload-Landingzones verbunden, wodurch optionale KI-Funktionen für ausgewählte Workloads angezeigt werden. Unter der Azure Zielzone werden Microsoft Copilot Studio, Microsoft Fabric und Microsoft 365 als integrierte Geschäfts-, Daten- und KI-Lösungen dargestellt. Unten stellen Datenquellen wie lokale Systeme, Dataverse, Microsoft 365, Azure Workloads und andere Clouds eine Verbindung mit diesen Lösungen her. Bidirektionale Pfeile zeigen die Integration zwischen Datenquellen, Microsoft Plattformen und Azure Workloads an.

KI in einer Azure Landing Zone plus Unternehmensintegration mit Microsoft Lösungen. Laden Sie eine PowerPoint Datei dieser Architektur herunter.

Detailliert

Ein oberer Abschnitt mit der Bezeichnung "Einheitliche Identität, Sicherheit und Governance in Azure, Microsoft, Multicloud- und lokalen Umgebungen" enthält Microsoft Agent 365, Microsoft Defender, Microsoft Entra und Microsoft Purview. Unten befindet sich ein großer Azure-Landezonenkasten, der die Plattform-Landezone und mehrere Workload-Landezonen enthält. Die Plattform-Zielzone, die von Plattformteams verwaltet wird, enthält Verwaltungsgruppenhierarchie mit Trennung zwischen zentralen Plattformressourcen für Sicherheit, Verwaltung, Netzwerk und Konnektivität und Identität. Azure Policy und Azure RBAC werden angezeigt, da sie auf die Verwaltungsgruppen angewendet werden. Ein Hinweis weist auf die Verantwortung des Plattformteams für die zentrale Verteilung von Workload-Landing-Zones an die Workload-Teams hin. Im Abschnitt "Workload-Zielzonen" wird gezeigt, wie Workloads unter der Azure Zielzonenarchitektur organisiert werden. Workloads werden in "Interne", "Online" und "Lokale Kategorien" gruppiert. Jede Workload erhält eine dedizierte Workload-Zielzone, die alle Umgebungen enthält, die dieser Workload zugeordnet sind. Typische Umgebungen umfassen Entwicklung, Test und Produktion mit jeder Umgebung, die aus einem oder mehreren Azure Abonnements besteht. Beispiele für interne Arbeitsauslastungen sind eine Microsoft Fabric Compute-Zielzone und eine Landungszone für Daten- und KI-Workload, die Dienste wie Azure Machine Learning, Azure Databricks, KI für Azure-Infrastruktur verwendet und Azure Data Lake Storage. Das Diagramm zeigt auch, dass Microsoft Findry-Ressourcen zu Workloadumgebungen hinzugefügt werden können, in denen KI-Funktionen erforderlich sind. Workload-Teams verwalten die Workload-Landing-Zones, die von der Plattform-Landing-Zone getrennt bleiben, welche von Plattform-Teams verwaltet wird.

KI in einer detaillierten konzeptionellen Azure Landing-Zone-Architektur. Laden Sie eine PowerPoint Datei dieser Architektur herunter.

Ausführlich + Integration

Diagramm: Konzeptionelle Architektur der Azure Zielzone. Eine oberste Ebene mit der Bezeichnung "Einheitliche Identität, Sicherheit und Governance" umfasst die Umgebung und umfasst Microsoft Agent 365, Microsoft Defender, Microsoft Entra und Microsoft Purview. Unten ist die Azure Landing Zone in eine Plattform-Landing Zone und Workload-Landing Zones unterteilt. Die Landing Zone der Plattform enthält eine Tenant Root Group mit einer Hierarchie der Verwaltungsgruppen. Verwaltungsgruppen organisieren zentrale Plattformressourcen für Sicherheit, Verwaltung, Identität und Konnektivität. Azure Policy und Azure RBAC werden in der gesamten Hierarchie angewendet. Workload-Zielzonen werden den Kategorien „Intern“, „Online“ und „Lokal“ zugeordnet, mit separaten Verwaltungsgruppen für Sandbox- und außer Betrieb genommene Ressourcen. Der Abschnitt "Workload-Zielzonen" zeigt Beispielworkloads. Jede Workload verfügt über eine dedizierte Workload-Landing Zone, die Produktions-, Test- und Entwicklungsumgebungen enthält. Beispiel für interne Workloads sind Microsoft Fabric Compute und eine Daten- und KI-Workload. Microsoft Foundry stellt eine Verbindung mit Workload-Zielzonen her und gibt an, dass KI-Funktionen zu ausgewählten Workloadumgebungen hinzugefügt werden können. Unter der Azure Zielzone werden Microsoft Copilot Studio, Microsoft Fabric und Microsoft 365 als integrierte Geschäfts-, Daten- und KI-Lösungen dargestellt. Unten stellen Datenquellen wie lokale Systeme, Dataverse, Microsoft 365, Azure Workloads und andere Clouds eine Verbindung mit diesen Lösungen her. Bidirektionale Pfeile zeigen die Integration zwischen Datenquellen, Microsoft Plattformen und Azure Workloads an.

KI in einer detaillierten konzeptionellen Azure-Landing-Zone-Architektur plus Unternehmensintegration mit Microsoft-Lösungen. Laden Sie eine PowerPoint Datei dieser Architektur herunter.

KI-Entscheidungsstruktur

Beginnen Sie, indem Sie den KI-Anwendungsfall identifizieren. Wenn das Ziel darin besteht, die individuelle Produktivität zu verbessern, verwenden Sie Microsoft 365 Copilot für Microsoft 365-Apps. Verwenden Sie produktinterne Copilots für Produkte wie Azure, GitHub, Fabric, Dynamics 365 oder Power Platform. Verwenden Sie rollenorientierte Copiloten für Rollen wie Sicherheit, Vertrieb, Service oder Finanzen. Wenn der Anwendungsfall allgemein ist, verwenden Sie Microsoft Copilot. Wenn Sie Microsoft 365 Copilot bereits verwenden und benutzerdefinierte Agents mit domänenspezifischen Fähigkeiten benötigen, verwenden Sie Erweiterungstools für Microsoft 365 Copilot. Wenn das Ziel darin besteht, Geschäftsfunktionen zu automatisieren, verwenden Sie Copilot Studio als SaaS-Tool, das die Erstellung und Bereitstellung von Agenten durch natürliche Sprache mit integrierten Preismodellen ermöglicht. Verwenden Sie Foundry als Entwicklungsplattform mit API-Zugriff auf Foundry Tools. Wenn Sie vordefinierte nicht-generative Modelle oder Azure KI-Suche für die Agentunterstützung benötigen, verwenden Sie Foundry Tools. Wenn Sie Machine Learning-Modelle mit Ihren eigenen Daten trainieren und bereitstellen müssen, verwenden Sie Microsoft Fabric, wenn Sie bereits in dieser Umgebung arbeiten. Andernfalls verwenden Sie Azure Machine Learning. Verwenden Sie Azure Container Apps für einfache KI-Ableitungen ohne Verwaltung der GPU-Infrastruktur (regionale Verfügbarkeit und Funktionsstatus variiert; überprüfen Sie die aktuelle serverlose GPU-Unterstützung). Wenn Sie Ihre eigenen Modelle mitbringen müssen, verwenden Sie Azure Virtual Machines (optional mit Azure CycleCloud oder Azure Batch) oder Azure Kubernetes Service für containerisierte Workloads.

Microsoft KI-Entscheidungsstruktur.

Plattform-Landing Zone

Die KI-Einführung sollte auf der vorhandenen Azure Landing Zone aufbauen, anstatt eine separate Plattformstruktur einzuführen. KI-Workloads verwenden dieselbe Verwaltungsgruppenhierarchie und Plattformfunktionen wie andere Azure Workloads. Organisationen benötigen in der Regel keine KI-spezifischen Verwaltungsgruppen. Stattdessen sollten Plattformteams vorhandene Governance- und Konnektivitätsfunktionen erweitern, um die von KI-Workloads verwendeten Azure-Dienste abzudecken.

Governancebaseline: Die vorhandene Azure Landing Zone-Governancebaseline sollte der Ausgangspunkt für KI-Workloads bleiben. Plattformteams sollten diese Grundlage erweitern, wenn KI-Dienste Anforderungen einführen, die in bestehenden Richtlinien nicht behandelt werden.

• Azure Policy: Organisationen sollten mit den Basisrichtlinien des platform landing zone accelerator beginnen. Plattformteams sollten dann Azure Policy Definitionen für die VON der Organisation genehmigten KI-Dienste hinzufügen, z. B. Microsoft Foundry-Modelle, Foundry Tools, Azure KI-Suche und Azure Virtual Machines. Durch die Anwendung dieser Richtlinien über die vorhandene Verwaltungsgruppenhierarchie erhalten KI-Workloads konsistente Leitplanken, ohne dass ein separates Governancemodell erforderlich ist. Die Microsoft-Anleitung unterstützt die Anwendung der KI-spezifischen Richtlinien über die Landing-Zone-Verwaltungsgruppenhierarchie, sodass Workloadressourcen sie erben.

• Netzwerkkonnektivität: Vorhandene Netzwerkmuster für Azure Landing Zones sollten auch die Grundlage für KI-Workloads bleiben. Plattformteams sollten gemeinsame Konnektivität und Netzwerkschutz erweitern, wenn KI-Workloads zusätzliche Anforderungen mit sich bringen, insbesondere für internetorientierte Dienste oder den Zugriff auf lokale Daten.

  • DDoS Protection: Für das Internet zugängliche KI-Workloads sollten Azure DDoS Protection verwenden. Das Plattformteam kann diesen Schutz als Teil der freigegebenen Netzwerkfunktionen des Unternehmens bereitstellen, anstatt von einzelnen Workload-Teams zu verlangen, dass sie einen eigenen Ansatz auf Plattformebene einrichten.

  • Hybridkonnektivität: Unternehmen, die von Azure KI-Workloads auf lokale Daten zugreifen, sollten die Konnektivität basierend auf ihren Leistungs- und Verfügbarkeitsanforderungen auswählen. Azure ExpressRoute bietet private Konnektivität und ist angemessen, wenn Organisationen vorhersagbare Konnektivität zu Azure benötigen. Azure VPN Gateway bietet verschlüsselte Konnektivität über das öffentliche Internet und kann für weniger anspruchsvolle Konnektivitätsanforderungen geeignet sein. Vorhandene Azure Anleitungen zur Landing Zone unterstützen auch VPN Gateway und ExpressRoute als Hybridverbindungsmuster.

Workload-Zielzonen

KI-Workloads verwenden dieselben Prinzipien der Workload-Landungszone wie andere Azure Workloads. Jede Workload sollte über eine eigene Workload-Landingzone verfügen und ein oder mehrere Azure-Abonnements verwenden, um Umgebungen basierend auf den Governance- und Isolationsanforderungen der Organisation zu trennen. Azure-Abonnements legen Grenzen für Bereiche wie Kontingent, Kosten, Governance und Sicherheit fest.

Das Plattformteam sollte Workload-Landing Zone-Abonnements für KI-Workloads unter der vorhandenen Verwaltungsgruppe platzieren, die die entsprechenden Governance-Steuerelemente bereitstellt. In der Regel gehören aus dem Internet erreichbare KI-Workloads zur Onlineverwaltungsgruppe. Interne KI-Workloads gehören in der Regel zur internen Verwaltungsgruppe („Corp“). Plattformteams sollten diese vorhandenen Abgrenzungen verwenden, anstatt Verwaltungsgruppen speziell für KI zu erstellen. Azure Policy Zuweisungen auf Managementgruppenebene bieten dann konsistente Plattformschutzschienen über KI und andere Workloads hinweg.

Reliability

KI-Workloads sollten die vorhandenen Verfügbarkeits- und Notfallwiederherstellungsstandards der Organisation verwenden. Plattformteams sollten die Azure Landing Zone vorbereiten, um mehrere Regionen zu unterstützen, damit Workload-Teams KI-Workloads in Regionen bereitstellen können, wenn ihre Geschäftskontinuitätsanforderungen die zusätzlichen Kosten und die Komplexität rechtfertigen. Der Azure-Leitfaden für Landing Zones empfiehlt ausdrücklich, die Plattform so zu entwerfen, dass sie Workload-Landing-Zones für mehrere Regionen unterstützen kann.

• Datenspeicherort: Der Datenspeicherort sollte auch Teil des regionalen Designs sein. Workloadteams sollten Abrufdaten in der Nähe der KI-Dienste platzieren, die diese Daten nutzen, wenn Latenz und Leistung wichtig sind. Die regionale Platzierung muss auch den Anforderungen an die Datenresidenz der Organisation entsprechen.

• Verfügbarkeit und Kapazität: KI führt zusätzliche regionale Überlegungen ein, da die Dienstverfügbarkeit, die Modellverfügbarkeit und die Kapazität je nach Azure Region variieren können. Organisationen sollten die Regionen identifizieren, in denen ihre genehmigten KI-Dienste und -Modelle unterstützt werden, bevor sie diese Regionen für KI-Workloads verfügbar machen.

• Failover: Workloadteams, für die ein regionales Failover erforderlich ist, sollten auch KI-Ressourcen berücksichtigen, von denen die Workload abhängig ist, z. B. Modellbereitstellungen und Abrufdaten. Der Wiederherstellungsentwurf sollte sicherstellen, dass die sekundäre Region über die Ressourcen und Daten verfügt, die zum Wiederherstellen der Workload erforderlich sind.

Unternehmensintegration

KI-Workloads sollten in Unternehmensplattformen mit den gleichen Architekturprinzipien wie andere Workloads integriert werden. Der wichtigste KI-spezifische Aspekt ist der Zugriff auf vertrauenswürdige Organisationsdaten.

Organisationen sollten einen einheitlichen Ansatz für Daten einrichten, mit dem regelkonform verwaltete Daten KI-Workloads zur Verfügung gestellt werden, ohne dass jedes Workloadteam separate Datenintegrationsmuster erstellen muss. Microsoft Fabric kann Organisationsdaten für Analyse- und KI-Szenarien vorbereiten und bereitstellen. Azure AI-Workloads können dann die entsprechenden Daten über genehmigte Integrationsmuster nutzen. Anleitungen zum Einrichten dieser Grundlage finden Sie unter Unified Data Platform.

Nächste Schritte

Die Überlegungen zur Architektur und Governance für eine Workload-Zielzone hängen von den KI-Plattformen und -Technologien ab, die der Workload verwendet. Die folgenden Hinweise bieten tiefere Architekturempfehlungen für verschiedene KI-Einführungsmuster.

AI auf Azure Plattformen

AI für Azure Infrastruktur