AI-Agent-Building

Eine belastbare FM-Agentenarchitektur besteht aus sieben Bausteinen: Prompt Engine, Kontext-Store, Wissensbasis, Integrationsschicht, Authentifizierung und Autorisierung, Monitoring und Audit, Fallback- und Freigabeschicht. Offizielle Google-Cloud-Architekturen und Produktdokumente decken diese Bausteine sauber ab: Agent Designer für No-Code-Flows, Vertex AI für Modellebenen, Grounding und Tool Use, Vertex AI Search bzw. Search API Grounding für Unternehmenswissen, IAM für Rechte, Observability/Logging für Betrieb und externe Datenspeicher für Sitzungs- und Langzeitkontext.

Die Prompt Engine ist nicht nur ein Texteingabefeld, sondern die fachliche Betriebsanweisung des Agenten. System Instructions definieren Rolle, Regeln, Antwortformat und Sprachverhalten. Für komplexe Requests empfiehlt Google, Kontext und Ziel klar zu strukturieren, negative Constraints an das Ende zu stellen, wenige, aber präzise Beispiele zu geben und strukturierte Outputs zu erzwingen, wenn nachgelagerte Systeme konsumieren. Im FM ist das besonders wichtig, weil Ergebnisse selten „schön“, sondern meistens „anschlussfähig“ sein müssen: JSON für Tickets, Tabellen für SLA-Abweichungen, Ampellogik für Prüfpflichten, standardisierte Maßnahmenlisten für Objektteams.

Der Kontext-Store entscheidet darüber, ob ein Agent nur im Augenblick klug wirkt oder über Sitzungen hinweg konsistent bleibt. Google beschreibt für agentische Architekturen kurzzeitigen Sitzungsstatus, Langzeitgedächtnis und externe Zustandsablage etwa über Memory Bank, Redis/Memorystore oder Datenbanken. Für FM-Anwendungen ist diese Trennung zentral: flüchtiger Chat-Kontext für Gesprächsverläufe, objektspezifischer Langzeitkontext für Historien, und systemischer Wahrheitskontext weiterhin im CAFM/DMS/ERP. Der Agent darf Kontexte halten; die führenden Stammdaten bleiben aber in den operativen Quellsystemen.

Die Wissensbasis sollte zweigeteilt werden. NotebookLM eignet sich hervorragend als kuratierte, quellengebundene Arbeitsumgebung für Regeln, Verträge, Handbücher, Betreiberdokumentation, Lessons Learned und Objektbriefings. Gleichzeitig ist NotebookLM keine selbstaktualisierende operative Datenbank: Quellen sind statische Kopien, Google-Drive-Originale müssen manuell synchronisiert werden, andere Quellen teils neu hochgeladen werden, und Antworten in NotebookLM sind exklusiv an die Notebook-Quellen gebunden. Für produktionsnahe Agents ist deshalb oft ein Suchindex oder eine RAG-Schicht auf Basis von Vertex AI Search oder einer eigenen Search API geeigneter, weil dort Synchronisierung, Suchendpunkte, Berechtigungen und Data-Stores kontrollierbarer sind.

Die Integrationsschicht ist der eigentliche Hebel für FM-Wertschöpfung. Offizielle Agent- und Connector-Dokumente zeigen, dass Gemini Enterprise Datenquellen und Tools wie Drive, Gmail, Calendar sowie Drittanbieter wie Jira, Confluence, SharePoint, OneDrive, Notion oder Zendesk anbinden kann. Für FM-Landschaften heißt das methodisch: dort, wo Standardconnectoren existieren, kann man schneller pilotieren; dort, wo proprietäre CAFM-, BMS- oder ERP-Systeme dominieren, ist Search API Grounding oder Function Calling gegen eigene Schnittstellen der robustere Weg. Function Calling eignet sich dabei für zwei Klassen von Fähigkeiten: Daten holen und Aktionen auslösen. Gerade letztere müssen im FM hinter Bestätigungs- und Validierungslogik stehen.

Authentifizierung und Autorisierung müssen rollenbasiert, granular und revisionsfest sein. Google empfiehlt Custom Roles für Least Privilege, weil vordefinierte Rollen oft zu weit reichen. Zusätzlich sollten Nutzer-Identität, Service-Accounts und Tool-Rechte getrennt werden: Ein Nutzer darf Tickets lesen, aber nicht schreiben; ein Agent darf Entwürfe erzeugen, aber keinen Auftrag freigeben; ein Connector darf auf eine Knowledge-Collection zugreifen, aber nicht auf HR-Dokumente. Für Google Workspace mit Gemini gilt zudem: Der Dienst greift nur auf Inhalte zu, für die der Nutzer berechtigt ist, und bestehende Schutzmechanismen wie DLP, IRM und gegebenenfalls Client-Side Encryption bleiben relevant.

Monitoring, Audit und Evaluation sind Pflicht, sobald der Agent mehr tut als brainstormen. Die offiziellen Architekturen nennen Cloud Logging, Cloud Monitoring und Audit Logs; die Gen-AI-Evaluationsdokumentation unterscheidet Final Response Evaluation und Trajectory Evaluation. Für FM bedeutet das, dass nicht nur das Ergebnis, sondern auch der Weg überwacht werden muss: Welche Quelle wurde genutzt? Welches Tool wurde aufgerufen? Wurde eine Eskalation ausgelöst? Wurde eine unsichere Annahme gemacht? Hat der Mensch den Vorschlag verworfen? Gute FM-Agenten werden nicht nur nach Antwortqualität gesteuert, sondern nach Prozessqualität.

Das Betriebsmodell ist im Google-Stack klar cloudorientiert. Agent Designer, NotebookLM, Gemini Enterprise und Vertex-AI-Architekturen sind als Cloud-Services bzw. cloudnahe Referenzarchitekturen dokumentiert. Daraus folgt für FM-Organisationen mit OT-Nähe, kritischen Infrastrukturen oder strengen Souveränitätsvorgaben: Die AI-Schicht sollte zunächst advisory bleiben, schreibende Rechte eng begrenzt werden, Datenresidenz aktiv konfiguriert werden und es muss immer einen manuellen Fallback auf native CAFM-/Ticketing-/SOP-Prozesse geben. Diese Schlussfolgerung wird dadurch verstärkt, dass Agent Schedules im Gemini-Umfeld Beschränkungen haben, nur in Multi-Regionen laufen, mit Verzögerung starten können und Credentials regelmäßig erneuert werden müssen; zugleich rät Google davon ab, sensible oder kritische Aufgaben automatisiert schedulen zu lassen.

Der sinnvollste Weg vom Einfall zum produktiven FM-Agenten ist kein Hackathon, sondern ein fachlich geführter Produktentwicklungsprozess. Startpunkt ist ein Use-Case-Canvas mit sieben Feldern: Prozessschritt, Schmerzpunkt, Zielentscheidung, Nutzerrolle, Quellsysteme, erlaubte Aktionen, Eskalationsgrenze. Erst wenn klar ist, welche Entscheidung besser werden soll und welche Folgen eine falsche Antwort hätte, lohnt sich die Modell- oder Toolauswahl. Diese Strenge passt sowohl zu testgetriebener Promptentwicklung bei Vertex AI als auch zum FM-Verständnis aus ISO 41001, wonach Leistungserbringung an Organisationszielen und Stakeholder-Anforderungen auszurichten ist.

An zweiter Stelle steht die Datenanforderungsklärung. Im FM scheitern Agenten selten an zu wenig GenAI, sondern an unklaren Objektschlüsseln, widersprüchlichen Stamm- und Anlagendaten, veralteten Vertragsständen oder nicht standardisierten Dokumentstrukturen. Genau hier sind die Hinweise von GEFMA zur standardisierten Datenbasis, zu Datenstrukturen und zu CAFM-Ausschreibungs- und Zertifizierungslogik hochrelevant. Parallel bestätigt auch die Fachliteratur, dass FM-Anwendungen von digitalen Technologien vor allem in Informations-, Instandhaltungs-, Energie- und Notfallmanagement liegen und dass unzureichende Datenverfügbarkeit ein zentrales Hemmnis ist.

Beim Prompt-Design gilt im FM: weniger Kreativität, mehr Betriebsdisziplin. Gute Agent-Prompts benennen Ziel, zulässige Quellen, Ausgabeformat, Verbote, Eskalationsregeln und Rückfragepflichten. Die offiziellen Vertex-AI-Leitfäden empfehlen, Aufgaben präzise zu formulieren, Kontext explizit zu machen, systemische Regeln in System Instructions auszulagern, Few-Shot-Beispiele für konsistente Formate einzusetzen und kritische Restriktionen am Ende des Prompts zu platzieren. Für das FM ist besonders wichtig, dass der Agent Unsicherheit nicht kaschiert, sondern ausweist, und sicherheits-, compliance- oder vertragsrelevante Themen automatisch hochstuft.

Ein sauberer Test- und Verifikationsworkflow besteht aus vier Ebenen. Zuerst Funktionstests: kann der Agent klassifizieren, extrahieren, zusammenfassen, finden? Dann Negativtests: reagiert er korrekt auf fehlende Daten, widersprüchliche Quellen, toxische oder manipulative Inputs? Danach Prozesstests: nutzt er die richtigen Tools in der richtigen Reihenfolge? Schließlich Freigabetests: erkennt er seine Grenzen und fordert Review ein? Die Google-Evaluationsdienste für Agents unterscheiden dafür sinnvoll zwischen Endergebnis und Trajektorie. In FM-Kontexten sollte diese technische Evaluation um verbetriebliche Abnahmen ergänzt werden: Betreiberpflichten, SLA-Tauglichkeit, Revisionsfähigkeit und Verständlichkeit für Disponenten.

Der Rollout sollte immer gestaffelt verlaufen. Stufe eins ist eine lesende oder entwerfende Assistenz ohne Schreibrechte. Stufe zwei ergänzt strukturierte Vorschläge mit obligatorischer menschlicher Freigabe. Stufe drei erlaubt begrenzte Aktionen in Nicht-Kernprozessen. Stufe vier ist Multi-Agent-Orchestrierung nur dort, wo Risiken, Logs, Monitoring und Notfallverfahren ausgereift sind. Parallel dazu braucht es Change-Management: Begriffsklärung, Schulung, Beispielbibliothek, Review-Methodik und AI-Literacy. Die Europäische Kommission weist ausdrücklich darauf hin, dass Deployers für ausreichende AI Literacy ihrer Mitarbeitenden sorgen müssen; bei High-Risk-Systemen ist Schulung für praktischen Umgang und Human Oversight noch wichtiger.

Die häufigsten Fehlerquellen bei FM-Agents sind erstaunlich vorhersehbar. Erstens Prompt Injection: Nutzer, Dokumente oder Anhänge können versuchen, Agentregeln zu überschreiben. Zweitens Insecure Output Handling: ein halluziniertes oder fehlerhaftes Ergebnis wird ungeprüft in ein Ticketsystem, eine Mail oder eine Datenbank übernommen. Drittens Sensitive Information Disclosure: der Agent verrät Vertragsinhalte, personenbezogene Daten oder vertrauliche Objektinformationen. Viertens Excessive Agency: der Agent erhält mehr Aktionsmacht als organisatorisch verantwortbar ist. Fünftens Overreliance: Menschen hören auf, kritisch zu prüfen. Diese Risiken werden in der Top-10-Systematik von OWASP ausdrücklich benannt und passen inhaltlich sehr gut zu FM-Anwendungsfällen.

Daraus folgen drei Fail-safe-Strategien. Erstens: Default to Draft. Der Agent erzeugt Entwürfe, Vorschläge und Warnungen, aber keine endgültigen Änderungen an Betreiberdokumenten, Auftragsdispositionen oder Vertragsakten. Zweitens: Default to Escalation. Bei Unsicherheit, Regelkonflikt, fehlender Quelle oder Sicherheitsbezug eskaliert der Agent automatisch an Mensch oder Fachteams. Drittens: Default to Source. Wenn die Wissenslage strittig ist, sind Originalquelle und System of Record maßgeblich, nicht die generative Formulierung. Diese Logik wird auch durch Grounding-Empfehlungen gestützt, die den Zweck verifizierbarer Quellen und Auditierbarkeit gerade für präzisionskritische Kontexte betonen.

Die menschlichen Freigabegrenzen sollten im FM schriftlich definiert werden. Immer menschlich freizugeben sind mindestens: sicherheits- und brandschutzrelevante Entscheidungen, Betreiberpflichten und Prüfpflichten, Vertragsauslegungen und Leistungsabgrenzungen, Freigaben von Beauftragungen und Kostenfolgen, Änderungen an Stammdaten mit Rechts- oder Abrechnungswirkung, Zutritts- und Überwachungskonfigurationen sowie personalbezogene Bewertungen. Google empfiehlt bei Function Calling ausdrücklich, Funktionsaufrufe mit erheblichen Folgen vor Ausführung mit dem Nutzer zu validieren; auch geplante Agent-Ausführungen, die andere Personen betreffen, werden im offiziellen Gemini-Umfeld zur Review angehalten.

Rechtlich besonders sensibel wird es dort, wo FM-Agents in Bereiche geraten, die der AI Act als high-risk behandelt. Zwei Zonen sind für FM besonders relevant. Erstens Beschäftigung und Worker Management: Systeme, die Aufgabenverteilung, Leistungsüberwachung, Beförderung oder Vertragsbeziehungen beeinflussen, sind hochriskant. Zweitens kritische Infrastruktur und sicherheitsrelevante Komponenten: Der AI Act benennt unter anderem Safety Components in kritischer Infrastruktur sowie sektorale Produktbereiche wie Lifte und Druckgeräte. Das bedeutet nicht, dass jeder FM-Agent automatisch high-risk ist. Es bedeutet aber, dass FM-Organisationen sehr genau unterscheiden müssen zwischen Assistenz für Dokumentation einerseits und AI, die in sicherheitskritische Steuerungs- oder Personalentscheidungen eingreift, andererseits.

Datenschutzrechtlich sind im FM vor allem drei Punkte entscheidend. Erstens dürfen nur zwecknotwendige Daten in den Agenten fließen. Zweitens müssen Daten aktuell genug sein, damit keine falschen betrieblichen Entscheidungen entstehen. Drittens dürfen Zugriffsmodelle nicht durch „bequeme Agentenfreigaben“ ausgehebelt werden. Gerade letzteres ist wichtig, weil die offizielle Agent-Designer-Hilfe ausdrücklich warnt: Wer einen Agent mit Datenquellen oder hochgeladenen Dateien teilt, teilt faktisch die Abfragemöglichkeit über diese Inhalte mit. Daraus folgt im FM eine klare Regel: Nie ein Agentensharing als Ersatz für sauberes Rechtemanagement missbrauchen.

Die Priorisierung von FM-Agents sollte auf fünf Kriterien beruhen: Nutzen, Umsetzbarkeit, Datenverfügbarkeit, Risiko und ROI-Zeitpunkt. Hohe Priorität haben typischerweise Use Cases mit hohem Volumen, stabilen Eingaben, klaren Zielausgaben und geringem Sicherheits- oder Rechtsrisiko. Niedrige Priorität haben Use Cases mit geringer Fallzahl, schwachen Daten, tiefer OT-Kopplung oder unmittelbarer Personen- bzw. Sicherheitswirkung. Diese Logik wird sowohl durch FM-Literatur zu typischen Einsatzfeldern als auch durch aktuelle Produktdokumentationen zu agentischen Integrations- und Groundingmustern gestützt.

Die folgende Tabelle ist eine synthetische Praxis-Priorisierung. Sie leitet sich aus FM-Kernprozessen, GEFMA-/ISO-orientierter Daten- und Prozesslogik sowie den derzeit dokumentierten Agenten-, Search- und Connector-Fähigkeiten ab. Sie ist bewusst nicht als Marktübersicht, sondern als Umsetzungsraster gedacht.

Die Prioritäten folgen einem einfachen Muster: hoch für lesende, prüfende und strukturierende Agents mit großem Volumen; mittel für analytische oder teilautomatisierende Agents; niedrig für Agents mit unmittelbarem Zutritts-, Personen- oder Arbeitssicherheitsbezug. In der Praxis sollte ein FM-Programm mit drei bis fünf High-Priority-Agents starten und erst nach stabilen Qualitätsnachweisen in schreibende oder multi-agentische Szenarien erweitern.

Die drei folgenden Use Cases sind so gewählt, dass sie unterschiedliche Reifegrade abbilden: ein hochvolumiger Serviceprozess, ein wissensintensiver Vergabeprozess und ein compliance-naher Instandhaltungsprozess. Zusammen decken sie den typischen Einstiegspfad eines FM-Agentenprogramms ab.

Der Ticket-Triage-Agent ist meist der beste Startpunkt, weil das Problemvolumen hoch, der Nutzen direkt sichtbar und die Automatisierung zunächst auf Vorschlagsniveau haltbar ist. Offizielle Agenten- und Function-Calling-Dokumente passen hier sehr gut: klarer Prompt, strukturierte Ausgabe, optionales Tooling für Assetsuche und Ticketanlage, Validierung vor schreibenden Aktionen.

System:

Du bist ein FM-Triage-Agent für eingehende Störungsmeldungen.

Nutze nur die bereitgestellten Quellen und Ticket-Metadaten.

Ziel: Kategorie, Priorität, betroffene Anlage, empfohlene Bearbeiterrolle und Rückfragebedarf bestimmen.

Wenn Brand-, Sicherheits-, Wasser-, Strom-, Gas- oder Personengefährdung erkennbar ist, setze safety_flag=true und eskaliere sofort.

Triff keine Annahmen über Gebäude, Anlage oder SLA, wenn sie nicht aus den Daten hervorgehen.

Gib ausschließlich JSON im vorgegebenen Schema aus.

User:

[Tickettext]

[Bild-/Dateihinweise]

[Objekt- und SLA-Kontext]

• Test-Szenarien: eindeutige HVAC-Störung; doppeldeutiges Ticket ohne Anlagennummer; Wasserschaden mit möglicher Gefahr; bewusst manipulativer Text im Anhang; Dublette zu bereits offenem Incident; Bild ohne ausreichend Kontext.

• Akzeptanzkriterien als Pilotziel: hohe Recall-Quote für sicherheitskritische Eskalationen, konsistente JSON-Ausgabe, robuste Rückfrageerkennung, keine automatische Schließung oder Beauftragung ohne menschliche Freigabe. Diese Kriterien entsprechen den dokumentierten Empfehlungen zu Grounding, strukturierten Outputs, Tool-Validierung und Trajectory Evaluation.

Der Ausschreibungs-Assistent ist im FM hochattraktiv, weil er viel Wissensarbeit bündelt: Leistungsbeschreibung, Objektkontext, Altverträge, Bewertungsmatrix, Bieterfragen und Angebotsvergleich. Gleichzeitig ist er ein klassischer Fall für „starke Assistenz, aber keine automatische Finalisierung“, weil Vergabe-, Vertrags- und Haftungsfragen berührt sind. GEFMA 440 und 444 liefern hier die fachliche Rahmung zur Ausschreibung und CAFM-Qualität; NotebookLM und Grounding helfen, verstreute Quellen belastbar zusammenzuziehen.

text

System:

Du bist ein FM-Ausschreibungs-Assistent.

Arbeite quellengebunden. Markiere jede Annahme und jeden fehlenden Sachverhalt.

Deine Aufgaben:

1. identifiziere Leistungsbausteine,

2. benenne Ausschreibungslücken,

3. schlage Bewertungs- und Eignungskriterien vor,

4. formuliere Rückfragen für unklare Punkte.

Erfinde keine Vertragsklauseln und gib keine Rechtsberatung.

Kennzeichne alles, was fachlich oder juristisch freigegeben werden muss.

User:

[Objektbeschreibung]

[Altvertrag]

[Leistungsgrenzen]

[relevante Standards und Wünsche]

vollständige Unterlagen; widersprüchlicher Altvertrag; fehlende Betreiberabgrenzung; fehlende Flächen-/Anlagenbasis; unzulässige Annahmen im Leistungsverzeichnis; Bieterfrage mit Mehrdeutigkeit. Akzeptanzkriterien: nachvollziehbare Quellenbezüge, sauber ausgewiesene Lücken, keine erfundenen Leistungsumfänge, klare Kennzeichnung menschlicher Freigabepunkte. Für diesen Use Case empfiehlt sich NotebookLM oder eine kuratierte Wissensbasis besonders stark, weil Ausschreibungsfehler oft aus verstreuten, veralteten oder impliziten Wissensständen entstehen.

Der Wartungsplan-Prüfer ist ein idealer Übergangsfall zwischen lesender und prüfender Assistenz. Er verbindet Anlagenstammdaten, Herstellerempfehlungen, Prüfpflichten, vorhandene Wartungsobjekte und tatsächliche Nutzungs- oder Laufzeitinformationen. Die größte Chance liegt darin, Lücken, Dubletten und offenkundige Frequenzfehler zu erkennen; die größte Gefahr liegt darin, aus unscharfen Regelquellen voreilige „Pflichten“ abzuleiten. Genau deshalb braucht dieser Agent restriktive Promptregeln und harte Eskalationsgrenzen.

text

System:

Du bist ein FM-Wartungsplan-Prüfer.

Vergleiche Wartungsobjekte nur mit bereitgestellten Quellen.

Unterscheide strikt zwischen:

- gesetzlicher oder normativer Pflicht,

- herstellerempfohlener Maßnahme,

- betrieblicher Best Practice,

- unbelegter Vermutung.

Wenn die Quellenlage unklar ist, gib "Freigabe durch Fachverantwortlichen erforderlich" aus.

Erzeuge eine Tabelle mit Anlage, Befund, Begründung, Quellenlage, Risikostufe, empfohlener Aktion.

User:

[Anlagenliste]

[Wartungspläne]

[Herstellerdokumente]

[Prüfprotokolle]

[Laufzeit-/Betriebsdaten]

Test-Szenarien: vollständige Anlagendaten; fehlende Herstellerunterlagen; mehrere widersprüchliche Frequenzen; Anlage ohne klare Objektzuordnung; rechtsähnliche Dokumente ohne Verbindlichkeit; Laufzeitdaten mit Ausreißern. Akzeptanzkriterien: saubere Trennung von Pflicht, Empfehlung und Vermutung; keine stillen Annahmen; Techniker können jeden Befund zur Quelle zurückverfolgen; Änderungen im CAFM nur nach Freigabe. Grounding, Quellenangabe und menschliche Aufsicht sind hier wichtiger als jede Form sprachlicher Eleganz.

Für die praktische Einführung sollten FM-Organisationen zwei Dinge gleichzeitig aufbauen: ein MVP mit echtem Nutzen und ein kleines, aber belastbares Governance-Betriebssystem. Ohne MVP bleibt AI abstrakt; ohne Governance produziert sie Schatten-Workflows, Qualitätsstreuung und Vertrauensverlust. Die technischen Grundlagen dafür sind in den offiziellen Dokumentationen gut ablesbar: Connectoren, Rollen, Data-Grounding, strukturierte Outputs, Logs, Audit, Evaluation und Freigaben sind keine Zusatzoptionen, sondern der Kern produktiver GenAI-Anwendungen.

Die folgende Roadmap ist eine praxisnahe Orientierungsplanung, keine Preis- oder Marktgarantie. Die Bandbreiten sind bewusst grob, weil Aufwand im FM hauptsächlich durch Integrationskomplexität, Datenqualität, Compliance-Tiefe und Change-Aufwand getrieben wird.

Kleinere Teams können mit Agent Designer oder kuratierten Gems sehr schnell lernen. Für organisationsweite FM-Agents mit mehreren Datenquellen, Schreibrechten, Audit und KPIs ist jedoch ein festes Kernteam nötig: fachlicher Process Owner, CAFM-/Datenverantwortlicher, IT-Integrationsverantwortlicher, Security/Privacy-Verantwortlicher, Test- und Qualitätslead, Change-/Enablement-Verantwortlicher. Wo Dienstleister im Betrieb mitwirken, sollte spätestens ab Limited Production auch die Dienstleistersteuerung in Reviews und Abnahmekriterien eingebunden sein.

Erstens: Beginnen Sie mit read-only oder draft-only. Zweitens: Verwenden Sie strukturierte Outputs für alles, was weiterverarbeitet wird. Drittens: Trennen Sie Wissensquellen, Transaktionssysteme und Agentengedächtnis. Viertens: Legen Sie für jeden Agent fest, welche Quellen „führend“ sind. Fünftens: erzwingen Sie Rückfragen statt stiller Annahmen. Sechstens: loggen Sie nicht nur Fehler, sondern auch verworfene Vorschläge und menschliche Overrules. Siebtens: halten Sie einen manuellen Notbetrieb bereit. Achtens: versionieren Sie Prompts, Testsets und Freigaberegeln.

Die folgenden Templates sind praxistaugliche Startmuster für FM-Agents. Sie übersetzen die offiziellen Prompting-Empfehlungen in FM-Kontexte.

text

Du bist ein FM-Agent für [Prozess].

Ziel: [genaues Ergebnis].

Erlaubte Quellen: [Liste].

Verboten: Annahmen ohne Quelle, Rechtsberatung, sicherheitsrelevante Freigaben.

Wenn Informationen fehlen oder Quellen widersprüchlich sind:

1. benenne die Lücke,

2. stelle maximal 3 Rückfragen,

3. setze status = "human_review_required".

Ausgabeformat: [JSON/Tabelle/Markdown].

text

Prüfe die folgende Erstantwort als unabhängiger Reviewer.

Suche nach:

- unbelegten Annahmen,

- fehlenden Quellen,

- Widersprüchen,

- Sicherheits- oder Compliance-Risiken,

- Punkten, die menschliche Freigabe erfordern.

Liefere:

1. Fehlerliste,

2. Risikostufe,

3. verbesserte Endfassung,

4. Freigabeempfehlung ja/nein.

text

Bevor du eine Aktion in einem externen System auslöst, prüfe:

- Ist die Nutzeranweisung eindeutig?

- Sind alle Pflichtfelder vorhanden?

- Ist die Aktion reversibel?

- Hat die Aktion Kosten-, Sicherheits-, Vertrags- oder Personenauswirkungen?

Wenn eine dieser Fragen kritisch ist, erzeuge nur einen Aktionsentwurf und fordere Bestätigung an.

Ein belastbarer Testkatalog sollte mindestens folgende Klassen enthalten: Normalfall, Mehrdeutigkeit, fehlende Daten, widersprüchliche Quellen, sicherheitskritischer Fall, prompt-injizierter Anhang, Datenschutzfall, Tool-Ausfall, stale data und erwartete Eskalation. Für produktive Steuerung genügen drei Kennzahlen nie; FM-Agenten brauchen ein ausgewogenes Set aus Qualitäts-, Sicherheits- und Betriebsmetriken. Die unten stehenden Metriken passen gut zu den dokumentierten Möglichkeiten von Evaluation, Logging und Audit.

Für den Aufbau eines FM-Agentenprogramms sind die wertvollsten Referenzen aktuell: offizielle Gemini-/Vertex-AI-Dokumentationen zu Agent Designer, Grounding, Function Calling, strukturierter Ausgabe, IAM und Agent Evaluation; NotebookLM-Dokumentationen zu Quellenlogik, Sharing und Datenschutz; ISO 41001 für FM-Systemverständnis; GEFMA 440/444/480 für Ausschreibung, CAFM-Qualität und Datenstrukturen; AI-Act- und GDPR-Quellen für Compliance; NIST AI RMF und OWASP LLM Top 10 für Governance und Sicherheitsmodell. Zusammengenommen ergeben diese Quellen kein Marketingbild, sondern eine belastbare Blaupause für sichere, praxisnahe Agenten im FM.