Das AI Agent Register: Eine plattformübergreifende Inventarvorlage für Copilot, Agentforce und benutzerdefinierte Agenten

Was das AI Agent Register steuert¶

Verwenden Sie das Register als abgeglichene Liste der Agentensysteme und ihrer Betriebsgrenzen für die Organisation. Jeder Datensatz verbindet eine stabile Agentenkennung mit einem Geschäftszweck, verantwortlichen Eigentümern, der aktuellen Version, der delegierten Autorität, dem Genehmigungspfad, Beweisen und dem Überprüfungsstatus. Das Register unterstützt vier wiederkehrende Fragen: Welche Agenten gibt es, wer antwortet für sie, was können sie tun und welche Aufzeichnungen belegen die Antwort.

Die nützliche Einheit ist eine bereitgestellte oder bereitstellbare Agentenkonfiguration mit einer eindeutigen Identitäts- oder Autoritätsgrenze. Erstellen Sie separate Datensätze, wenn zwei Umgebungen, Identitäten, Releases oder Geschäftsprozesse unterschiedliche Berechtigungen oder Genehmigungsregeln haben. Durch die Gruppierung unter einem Markennamen wird die Grenze verdeckt, die ein Zugriffsprüfer oder Vorfall-Responder benötigt.

Beziehen Sie aktive, Pilot-, Draft-, suspendierte und pensionierte Agenten ein, solange ihre Aufzeichnungen relevant bleiben. Erfassen Sie Kopiloten, die Empfehlungen oder Entwürfe abgeben, Agenten, die Tools oder APIs aufrufen, geplante Agenten-Workflows, für Mitarbeiter verfügbare Anbieteragenten und benutzerdefinierte Orchestratoren, die Aktionen auswählen oder sequenzieren können. Zeichnen Sie das System auf, auch wenn die Klassifizierung unsicher ist; Verwenden Sie das Feld „Einschränkungen“, um die Unsicherheit beizubehalten.

• Im Geltungsbereich: Vom Anbieter erstellte Agenten, von Mitarbeitern erstellte Agenten, benutzerdefinierte Agenten, eingebettete Agenten, Agenten-Workflows und Agentenanwendungen mit einem bestimmten Zweck oder einer klaren Berechtigungsgrenze.
• Getrennte Datensätze: Produktions- und Testinstanzen mit unterschiedlichen Daten, Identitäten, Tools, Besitzern oder Genehmigungsrichtlinien.
• Lebenszyklusstatus: vorgeschlagen, Entwurf, Pilot, aktiv, ausgesetzt, im Ruhestand und unbekannt.
• Offene Lücken: fehlende Identität, ungeklärter Besitzer, unvollständige Toolliste, nicht verfügbare Trace-Daten und nicht verifizierte Anbietermetadaten.

Laden Sie das Register herunter und starten Sie es¶

Das AI Agent Register CSV wird in Tabellenkalkulationstools geöffnet und in gängige Governance-, Asset-Management-, Daten- und Ticketing-Systeme importiert. Die erste Datenzeile ist synthetisch und deutlich mit EXAMPLE-001 gekennzeichnet. Kopieren Sie es, um den erwarteten Detaillierungsgrad zu erfahren, und löschen Sie es dann, bevor Sie Ihre Grundgesamtheit veröffentlichen.

Behalten Sie nach Möglichkeit einen Wert pro Feld bei. Verwenden Sie stabile IDs, kanonische Systemnamen, ISO-Daten, dauerhafte Beweislinks und benannte Rollen. Notieren Sie die Bereitstellungsgrenze in environment. Erfassen Sie die Rolle oder Person, die die Überprüfung abgeschlossen hat, in reviewed_by neben last_reviewed_at. Wenn ein Wert unbekannt ist, schreiben Sie unknown, weisen Sie einen Eigentümer für die Lücke zu und verwenden Sie next_review_due, um ein Schließungsdatum festzulegen. Eine leere Zelle kann nach einem Massenimport vollständig aussehen.

Version 1.0 der Vorlage enthält die sechs erforderlichen Kontrollfelder sowie die Felder Erkennung, Umgebung, Überprüfungsbescheinigung, Identität, Freigabe, Überwachung, Widerruf, Aufbewahrung und Anspruchsgrenze. Fügen Sie nach dem Standardsatz organisationsspezifische Spalten hinzu, damit zukünftige Lieferantenexporte und Einreichungen der Geschäftseinheiten vergleichbar bleiben.

Die sechs erforderlichen Kontrollfelder¶

Ein Datensatz ist für die Überprüfung bereit, wenn diese sechs Felder operative Antworten enthalten. Eine Berufsbezeichnung, ein Produktname oder ein Richtlinienlink können zu einer Antwort beitragen; es vervollständigt selten einen. Nennen Sie die Person oder das Team, die bzw. das die Steuerung betreibt, und die genaue Grenze, deren Eigentümer sie sind.

Verwenden Sie eine Skala für die Betriebsautonomie¶

Autonomie gehört ins Register, weil sie das Steuerungsdesign verändert. Verwenden Sie die fünfstufige Skala unten als interne Kurzform und behalten Sie die Klartextdefinition neben der Stufe bei. Eine Ebene allein kann keinen komplexen Arbeitsablauf beschreiben.

Diese Skala ist eine Governance-Konvention für die Triage. Es enthält keine rechtliche Einstufung, Sicherheitsbeurteilung oder Zertifizierung. Ein A1-Agent, der eine Folgeentscheidung entwirft, erfordert möglicherweise eine strengere Prüfung als ein A3-Agent, der eine umkehrbare Wartungsmaßnahme durchführt. Bewerten Sie Auswirkungen, Reversibilität, betroffene Personen, Datensensibilität und Autorität mit der Ebene.

Erfassen Sie Berechtigungen als Autoritätskette¶

Beginnen Sie mit der Agentenidentität: Dienstprinzipal, Workload-Identität, Agentenbenutzer, OAuth-Client, API-Schlüsselbesitzer oder vom Endbenutzer delegierte Sitzung. Benennen Sie dann jedes Tool und jede Aktion, den Ressourcenbereich, die Datengrenze, die Anmeldeinformationsquelle, die Zeit- oder Zweckbeschränkung und die Richtlinie, die die Verwendung zulässt. Der AI-Agent-Berechtigungsleitfaden bietet die tiefergehende Zugriffsüberprüfungsmethode.

Behalten Sie die zugewiesenen und beobachteten Befugnisse in getrennten Bereichen bei. Die zugewiesene Autorität stammt von IAM, Berechtigungssätzen, Connector-Konfiguration, Richtlinien-Repositorys, Tool-Manifesten und Genehmigungsregeln. Die beobachtete Autorität ergibt sich aus Ausführungen, Ablaufverfolgungen, API-Gateway-Datensätzen, Datenbank-Überwachungsprotokollen, Nachrichtenübermittlungsdatensätzen und nachgelagerten Statusänderungen. Unterschiede zwischen den beiden werden zu Überprüfungsergebnissen.

Das Register fasst die aktuelle Autorität zusammen und weist auf ihre Quellen hin. IAM-, Richtlinien-, Quellcodeverwaltungs- und Laufzeitdatensätze behalten ihre eigene Autorität. Aktualisieren Sie die Zusammenfassung nach einer Gewährungs-, Tool-, Identitäts-, Modell-, Eingabeaufforderungs-, Daten-, Bereitstellungs- oder Workflow-Änderung.

• Identität: stabile ID, Identitätstyp, Aussteller, Anmeldeinformationseigentümer und Umgebung.
• Tool-Berechtigung: Tool oder API, zulässige Aktionen, Ressourceneinschränkungen und verweigerte Aktionen.
• Datenautorität: Datensätze, Felder, Gerichtsbarkeiten, Vertraulichkeit, Aufbewahrung und Exportgrenzen.
• Delegation: Sponsoring-Prinzip, Zweck, Umfang, Dauer und Widerrufspfad.
• Beobachtete Nutzung: Ablaufverfolgungszeitraum, letzter beobachteter Zeitstempel, ausgeführte Aktionen und ungetestete Gewährungen.

Berührte Kartensysteme und nachgelagerte Effekte¶

Listen Sie jedes System auf, das der Agent lesen, ändern, benachrichtigen oder die Änderung einer anderen Komponente veranlassen kann. Beziehen Sie die sichtbare Geschäftsanwendung und den weniger sichtbaren Pfad über Suchindizes, Vektorspeicher, Warteschlangen, Planer, Toolserver, Gateways, Dateispeicher, Datenbanken, E-Mail, Chat und externe APIs ein.

Zeichnen Sie Effekte auf der Aktionsebene auf. „CRM-Zugriff“ verbirgt, ob der Agent einen Fall liest, eine Berechtigung ändert, eine Gutschrift ausstellt oder eine Kundennachricht sendet. Die Aktion bestimmt Genehmigungs-, Überwachungs-, Nachweis- und Rollback-Anforderungen.

Verknüpfen Sie die agentenübergreifende Delegation explizit. Wenn ein Agent einen anderen Agenten oder Workflow zum Handeln auffordert, zeichnen Sie beide Systeme und die zwischen ihnen übertragene Autorität auf. Der Upstream-Datensatz sollte die delegierte Aktion identifizieren; Der Downstream-Datensatz sollte den Auftraggeber und die Richtlinie identifizieren, die ihn akzeptiert haben.

Schreiben Sie Genehmigungsregeln, die ausgeführt werden können¶

Ein Genehmigungsfeld benötigt die Aktion, die Auslösebedingung, den erforderlichen Genehmiger, das Antwortfenster und das Ergebnis. „Human in the Loop“ lässt jeden Teil ungelöst. Schreiben Sie Regeln wie: „Rückerstattungen über 250 EUR werden vor der Ausführung pausiert; ein Leiter des Customer Operations-Teams genehmigt oder lehnt ab; die Anfrage läuft nach vier Stunden ab; eine Ablehnung führt zu keiner nachgelagerten Änderung.“

Benennen Sie den menschlichen Aufsichtseigentümer für den Workflow und die autorisierten Entscheidungsrollen für jedes Gate. Zeichnen Sie auf, was der Prüfer sieht, welche Alternativen er wählen kann, wie er den Workflow stoppt und wie Überschreibungen protokolliert werden. Bewahren Sie die Entscheidung, Begründung, Richtlinienversion, Agentenfreigabe, Eingabereferenzen, Zeitstempel und Downstream-Ergebnisse am Beweisort auf.

Die Genehmigung schützt die Aktion nur, wenn der Agent das Tor nicht umgehen kann. Überprüfen Sie den Ausführungspfad und testen Sie Ablehnung, Zeitüberschreitung, Widerruf, doppelte Anforderungen und Downstream-Fehler. Eine Grundsatzerklärung allein kann die Durchsetzung nicht nachweisen.

Wählen Sie Beweisorte aus, die einer Überprüfung standhalten¶

Weisen Sie jede Aufzeichnung auf einen dauerhaften Beweis für die genannte Veröffentlichung und den genannten Zeitraum hin. Zu den nützlichen Quellen gehören Identitäts- und Gewährungs-Snapshots, genehmigte Konfigurationen, Richtlinienentscheidungen, Genehmigungsaufzeichnungen, Tool-Call-Traces, Vorher-Nachher-Status, Vorfallaufzeichnungen, Änderungsüberprüfungen, Zugriffsüberprüfungen sowie Aufbewahrungs- oder Löschergebnisse.

Verwenden Sie Referenzen, die ein autorisierter Prüfer nach einem Wechsel des Betriebsteams abrufen kann. Erfassen Sie das Datensatzsystem, die Objekt- oder Abfrage-ID, den Aufbewahrungszeitraum, den Integritätsmechanismus, den Zugriffseigentümer und bekannte Erfassungslücken. Eine Dashboard-URL ohne stabile Abfrage oder Zeitraum verursacht vermeidbaren Umbauaufwand.

KLA kann die Betriebsaufzeichnung im Agent Registry verwalten, deklarierte Funktionen über den Tool Catalog verbinden, Folgeentscheidungen über den Decision Desk weiterleiten, Auswirkungen im Lineage Explorer verfolgen und Überprüfungsartefakte im Evidence Room aufbewahren. Die Abdeckung hängt weiterhin von den integrierten Systemen, den gesammelten Beweisen und den konfigurierten Kontrollen ab. Das Register bietet keine Bescheinigung oder einen Rechtsschluss.

Füllen Sie Microsoft Copilot- und Agent Builder-Datensätze aus¶

Beginnen Sie mit dem Power Platform-Inventar für Copilot Studio- und Microsoft 365 Copilot Agent Builder-Ressourcen, die auf Power Platform basieren. Exportieren Sie den Inventar- und Kartenanzeigenamen, die Plattform-ID, die Umgebung, den Ersteller oder Besitzer, den Veröffentlichungsstatus, die Authentifizierung, Konnektoren, Konnektorvorgänge, Kanäle und Funktionen in das gemeinsame Schema.

Gleichen Sie diesen Export mit der Microsoft 365 Admin-Center-Agent-Ansicht, Entra-Identitäten und -Zuschüssen, Bereitstellungsdatensätzen und Ausführungsnachweisen ab. Microsoft erklärt, dass die beiden Verwaltungsoberflächen unterschiedliche Bevölkerungsfragen beantworten: Der Power Platform-Inventar umfasst Agenten, die auf Power Platform erstellt wurden, einschließlich Entwürfen; Die Microsoft 365-Ansicht deckt Agenten ab, die Mandantenbenutzern aus einer größeren Anzahl von Quellen zur Verfügung stehen.

Behalten Sie die dokumentierten Einschränkungen von Microsoft in limitations_and_open_questions bei. Das Copilot Studio-Inventarschema schließt klassische V1-Agenten aus, lässt möglicherweise Identitätsfelder weg, spiegelt die veröffentlichte Konfiguration wider, wenn ein neuerer Entwurf vorhanden ist, und begrenzt detaillierte Funktionsressourcen. Diese Grenzen machen die Versöhnung zu einem Teil der Kontrolle.

• Exportieren Sie das Power Platform-Inventar mit stabilen IDs und Umgebungsfeldern.
• Export- oder Überprüfungsagenten, die über das Microsoft 365 Admin Center verfügbar sind.
• Treten Sie Entra-Anwendungs- oder Agentenidentitäten, Zuschüssen, Eigentümern und Anmeldeinformationskontrollen bei.
• Konnektorvorgänge zu Geschäftsaktionen und Datengrenzen auflösen.
• Vergleichen Sie zugewiesene Konnektoren und Zuschüsse mit aktuellen Ausführungsspuren.
• Fügen Sie klassische, benutzerdefinierte, Drittanbieter-, Entwurfs- und unzugängliche Datensätze als explizite Lücken hinzu.

Füllen Sie Salesforce Agentforce-Datensätze aus¶

Verwenden Sie Setup und Agentforce Studio, um Agentdefinitionen und stabile IDs aufzulisten. Salesforce dokumentiert, wie eine Agentforce-Agenten-ID abgerufen wird, einschließlich des BotDefinition-Objekts, das von aktuellen Agenten verwendet wird. Verknüpfen Sie jede Definition mit ihrer Umgebung, ihrem Lebenszyklusstatus, ihren Themen oder Aktionen, ihrem Datenzugriff, ihrer Bereitstellung und ihrem Geschäftszweck.

Zeichnen Sie den Agentforce-Agentenbenutzer, das Profil, die Berechtigungssätze, den Kontext der verbundenen Anwendung oder der API sowie jede aufgerufene Aktion auf. Gleichen Sie Verwaltungsdaten mit Agentforce DX-Quellmetadaten, Release-Änderungen, Audit-Datensätzen und Laufzeitinteraktionen ab. Quellmetadaten helfen bei der Identifizierung des erklärten Designs; Identitäten, Berechtigungen und Spuren zeigen die Betriebsgrenzen.

Behalten Sie Salesforce- und Microsoft-Datensätze im gleichen Kontrollschema mit sechs Feldern. Plattformspezifische IDs und Konfigurationen bleiben wertvoll, während die normalisierten Felder es einem Eigentümer ermöglichen, Agenten über Geschäftsprozesse und Anbieter hinweg zu überprüfen.

Finden Sie benutzerdefinierte Agenten und Schatten-KI¶

Benutzerdefinierte und von Mitarbeitern erstellte Agenten kommen selten über einen Inventarendpunkt an. Bauen Sie die Kandidatenpopulation aus Repositorys, Bereitstellungsplattformen, Workload-Identitäten, API-Gateways, Modellanbieterkonten, Tool- und MCP-Serverkatalogen, Planern, Warteschlangen, Secrets-Managern, Observability-Daten, Browser- oder Kollaborationsintegrationen, Beschaffung, Ausgaben, SSO-Anwendungen, Support-Tickets und Architekturdatensätzen auf.

Suche nach Betriebssignalen: Modell-API-Aufrufe in Kombination mit Tool-Aufrufen, nicht-menschliche Identitäten, die Geschäftssysteme aufrufen, geplante LLM-Jobs, Agent-SDK-Abhängigkeiten, Tool-Manifeste, Agent-Karten, Eingabeaufforderungen mit Aktionsanweisungen und wiederkehrende Genehmigungsnachrichten. Validieren Sie Kandidaten mit den technischen und geschäftlichen Eigentümern, bevor Sie ihnen Lebenszyklus und Autonomie zuweisen.

Der Shadow AI Risk Guide behandelt die Aufnahme und Reaktion für nicht deklarierte Systeme. Bewahren Sie die Erstaufzeichnung auch dann auf, wenn der Eigentümer unbekannt ist. Die ungelösten Felder „Eigentümer“, „Identität“, „Berechtigung“ und „Beweis“ definieren den Eindämmungs- und Untersuchungsrückstand.

Führen Sie einen reproduzierbaren Populationszyklus durch¶

Durch den Abgleich wird ein Register verlässlich. Behalten Sie für jeden Zyklus das Extraktionsdatum, die Quelle, die Abfrage- oder Exportmethode, die Datensatzanzahl, Ausschlüsse, Verknüpfungen, Duplikatregeln, den Prüfer und ungelöste Unterschiede bei.

• 1. Definieren Sie den Geltungsbereich. Benennen Sie Umgebungen, Geschäftseinheiten, Plattformen, benutzerdefinierte Stacks, Lebenszyklusstatus und das Standsdatum.
• 2. Extrahieren. Bewahren Sie rohe Lieferanten-, IAM-, Repository-, Beschaffungs-, Gateway- und Laufzeitquelldateien mit Zeitstempeln auf.
• 3. Normalisieren. Ordnen Sie stabile IDs und Plattformfelder der gemeinsamen Vorlage zu, ohne Quell-IDs zu verwerfen.
• 4. Match. Verknüpfen Sie Plattformdefinitionen mit Identitäten, Eigentümern, Bereitstellungen, Tools, Systemen, Richtlinien und Beweisen.
• 5. Deduplizieren. Führen Sie separate Aufzeichnungen, wenn Umgebung, Autorität, Genehmigung oder Release-Grenzen unterschiedlich sind.
• 6. Überprüfen. Bitten Sie geschäftliche und technische Eigentümer, Zweck, Auswirkungen, aktuellen Status und ungelöste Lücken zu bestätigen.
• 7. Beobachten. Vergleichen Sie die zugewiesene Autorität mit einem definierten Zeitraum von Toolaufrufen und nachgelagerten Effekten.
• 8. Beheben. Weisen Sie fehlende Eigentümer, übermäßige Zuschüsse, fehlende Genehmigungen, unbekannte Systeme und Beweislücken zu.
• 9. Attest. Erfassen Sie den Prüfer in reviewed_by, das Datum in last_reviewed_at, Quellen, Ausnahmen und den nächsten Überprüfungs- oder Änderungsauslöser.

Legen Sie den Überprüfungsrhythmus und die Änderungsauslöser fest¶

Wählen Sie ein risikobasiertes maximales Überprüfungsintervall und öffnen Sie den Datensatz erneut, wenn eine wesentliche Änderung auftritt. Arbeitsabläufe mit hoher Auswirkung oder hoher Autonomie erfordern möglicherweise kontinuierliche Bestandskontrollen und häufige Eigentümerüberprüfungen. Stabile reine Draft-Assistenten können ein längeres Intervall rechtfertigen.

Verwenden Sie Ereignisauslöser für den Austritt des Eigentümers, eine neue Umgebung, eine Modell- oder Releaseänderung, eine Identitäts- oder Berechtigungsänderung, ein neues Tool oder eine neue Datendomäne, einen geänderten Genehmigungsschwellenwert, eine neue externe Kommunikation, eine Richtlinienausnahme, einen Vorfall, unerklärliches Verhalten, eine Änderung der Anbieterfähigkeit und die Einstellung. Zeichnen Sie den Auslöser und die Antwort des Prüfers auf.

Die Außerbetriebnahme erfordert einen abschließenden Kontrolldurchgang: Bereitstellungen und Zeitpläne deaktivieren, Identitäten und Anmeldeinformationen widerrufen, Tool-Zuweisungen entfernen, erforderliche Beweise aufbewahren, Abhängigkeiten aktualisieren und Lösch- oder Aufbewahrungsaktionen zuweisen. Halten Sie die zurückgezogenen Aufzeichnungen für den geltenden Beweiszeitraum auffindbar.

Halten Sie die Pflichten des EU-KI-Gesetzes ein und registrieren Sie Ansprüche präzise¶

Ein internes KI-Agentenregister unterstützt die Governance und kann die Arbeit für das EU-KI-Gesetz unterstützen. Es handelt sich um ein von der formellen Registrierung in der EU-Datenbank getrenntes Artefakt. Artikel 71 regelt die EU-Datenbank für bestimmte Hochrisiko-KI-Systeme mit rollen- und systemspezifischen Registrierungsdaten. Bestätigen Sie alle Pflichten gemäß Artikel 49 oder 71 anhand des aktuellen Gesetzestextes und eines qualifizierten Anwalts.

Artikel 26 legt Pflichten für Betreiber von Hochrisiko-KI-Systemen fest. Relevante Aufzeichnungen können Gebrauchsanweisungen, zugewiesene menschliche Aufsicht, Eingabedatenkontrollen, Überwachung, Protokolle unter der Kontrolle des Betreibers, Vorfall- oder Risikohinweise, Arbeitnehmerinformationen und Zusammenarbeit umfassen. Die Anwendbarkeit hängt vom System, der Rolle und den Fakten ab.

Verwenden Sie article_26_applicability, um eine qualifizierte Beurteilung zu erfassen, oder review required. Das Feld selbst weist keine Klassifizierung oder Konformität nach. Befolgen Sie die Artikel-26-Checkliste für Betreiber für die Überprüfung auf Verpflichtungsebene und bewahren Sie die ausgefüllte Checkliste zusammen mit den Registernachweisen auf.

Anspruchsgrenzen für das abgeschlossene Register¶

Beschreiben Sie das fertige Ergebnis als eine abgeglichene Grundgesamtheit für die getesteten Quellen, Umgebungen, Geschäftseinheiten und das getestete Datum. Geben Sie die Extraktionsmethoden, bekannte blinde Flecken, ungelöste Datensätze und den Prozentsatz der Datensätze mit verifizierten Eigentümern, Identitäten, Berechtigungen, Genehmigungsregeln und abrufbaren Beweisen an.

Vermeiden Sie eine „vollständige Unternehmensinventur“, es sei denn, ein unabhängiger Abgleich unterstützt genau diesen Umfang. Für Lieferantenexporte gelten dokumentierte Grenzen. Die Laufzeitbeobachtung hat ein Zeitfenster. Ruhende Wirkstoffe erzeugen möglicherweise keine Spuren. Gemeinsame Identitäten können die Zuordnung verschleiern. Von Mitarbeitern erstellte und extern gehostete Agents bleiben möglicherweise außerhalb der verwalteten Erkennungspfade.

Die Vorlage organisiert die Governance-Arbeit. Es bietet keine Sicherheitsgarantie, Konformitätsbewertung, gesetzliche Registrierung oder Rechtsberatung. Diese Schlussfolgerungen erfordern eigene Kriterien, Beweise, Tests und verantwortliche Gutachter.