Ein gutes Architekturprojekt ist selten unsichtbar. Es wird fotografiert, publiziert, in Wettbewerben prämiert, in Fachmedien besprochen und auf internationalen Plattformen geteilt. Wer das Gebäude betrachtet, versteht sofort eine Leistung: Jemand hat das entworfen, jemand hat es durchgesetzt, jemand hat es gebaut. Fragt man ein KI-System nach dem Gebäude, kann es Ort, Jahr und oft einen Büronamen nennen. Fragt man, wer den Entwurf verantwortet hat, welche Person die Projektleitung hatte, welche Büros in welcher Konstellation beteiligt waren und welche Kompetenz eine bestimmte Person durch welche Projekte belegt, braucht die Antwort eine präzisere Entity-Struktur.
Offenlegung vorab: richresults.ai veröffentlicht diesen Guide und bietet AEO, GEO und Entity Building für Organisationen, Marken und Experten selbst an. Methode und Rolle von richresults.ai werden offengelegt, damit die Argumentation selbst eingeordnet werden kann.
01 Die kurze Antwort
Das Projekt trägt die Sichtbarkeit. Die Rolle gehört zur Person.
Ein Projekt kann von einem Büro stammen, von mehreren Büros in Arbeitsgemeinschaft oder von einem Büro mit Partnerbüros und Fachplanern. Innerhalb jedes Büros haben Personen unterschiedliche Rollen: Entwurf, Projektleitung, Bauleitung, Fachplanung, Wettbewerbsbearbeitung. Ein Büro ist kein Architekt. Eine Beteiligung ist keine alleinige Urheberschaft. Ein Award für ein Projekt ist keine persönliche Auszeichnung jedes Beteiligten und ein Wettbewerbserfolg ist nicht automatisch ein realisiertes Gebäude. AEO verbindet die Beziehungen zwischen Büro, Projekt, Personen, Rollen, Gebäudetypen, Orten, Wettbewerben, Publikationen und externer Evidenz so, dass KI-Systeme verstehen können, wer woran in welcher Rolle beteiligt war und welche Quellen genau diese Zuordnung stützen.
02 Warum Architektur ein besonderes Entity-Problem hat
Die Reputation liegt beim Objekt. Die Expertise liegt bei Personen.
Der digitale Fußabdruck der Architektur ist projektzentriert: Projektfotos, Publikationen, Plattformeinträge, Award-Listen, Wettbewerbsergebnisse. Das Gebäude wird berühmt, manchmal auch der Büroname. Die Personen dahinter erscheinen dagegen häufig nur als Gründername im Bürotitel oder als Zeile im Impressum einer Publikation. Für Bauherren, Auslober und Fachpresse ist aber genau die Personenfrage entscheidend: Wer hat das entworfen, wer hat vergleichbare Aufgaben schon einmal verantwortet, wem kann man ein ähnliches Projekt anvertrauen? Ein KI-System kann diese Fragen nur beantworten, wenn die Beziehung zwischen Projekt, Büro und Person maschinenlesbar existiert und nicht nur in der Bildunterschrift einer Fachzeitschrift.
Viele Beteiligte, verschiedene Rollen, mehrere Büros.
Kaum ein relevantes Projekt entsteht durch eine einzelne Person. Es gibt Partnerbüros, Arbeitsgemeinschaften, Generalplaner, Fachplaner für Tragwerk, Technik und Landschaft, wechselnde Teams über lange Projektlaufzeiten. Genau deshalb ist Attribution hier das eigentliche Problem, nicht die Sichtbarkeit. Die nützliche Logik lautet: Das Projekt hat eine dokumentierte Beteiligungsstruktur aus einem oder mehreren Büros. Jede Person hat eine konkrete Rolle bei einem konkreten Projekt. Ein Award gilt für die konkret ausgezeichnete Entity. Eine Publikation belegt nur die Beteiligten, die sie tatsächlich nennt. Wer diese Struktur zu einem pauschalen Wir-haben-das-gebaut verschmilzt, macht dem KI-System die Zuordnung nicht leichter, sondern unmöglich präzise.
In Deutschland existiert eine reale Personenebene: die Kammer.
In Deutschland ist die Berufsbezeichnung Architektin oder Architekt geschützt. Führen darf sie nur, wer in die Architektenliste einer Länderarchitektenkammer eingetragen ist; geregelt ist das in den Architektengesetzen der Bundesländer, dokumentiert unter anderem bei der Bundesarchitektenkammer. Das ist eine formale, externe, personenbezogene Evidenzebene: Sie belegt, dass eine konkrete Person die geschützte Berufsbezeichnung führen darf. Sie belegt aber keine Projektbeteiligung und keine Rolle. Der Kammereintrag beantwortet, wer als Architekt eingetragen ist. Er beantwortet nicht, wer dieses Gebäude entworfen hat. Beide Ebenen gehören in die Entity-Struktur, aber als getrennte Beziehungen.
03 Drei Ebenen, die KI-Systeme nicht verwechseln sollten
Büro, Projekt und Person bedeuten Unterschiedliches.
1. Die Büro- oder Organization Entity. Hier gehören hin: der offizielle Name, die Rechtsform, die Partnerstruktur, Standorte, Gründungsgeschichte, Kompetenzfelder, sofern durch reale Projekte gedeckt, Referenzlisten und Büroprofile. Diese Ebene beantwortet die Frage: Was ist dieses Büro als Organisation und welche Projekte gehören nachweisbar zu seiner Beteiligungsgeschichte?
2. Die Projekt-Entity. Das konkrete Werk: Gebäude oder Vorhaben, Ort, Gebäudetyp, Zeitraum, Bauherr, sofern öffentlich dokumentiert, und vor allem die tatsächliche Beteiligungsstruktur: welches Büro oder welche Büros, in welcher Konstellation, mit welchen Fachplanern. Dazu die projektbezogene Evidenz: Wettbewerbsergebnis, Awards, Publikationen, Fachbesprechungen. Diese Ebene beantwortet die Frage: Was ist dieses Projekt und wer war daran dokumentiert beteiligt?
3. Die Person-Entity. Der Mensch: Name, Berufsbezeichnung, sofern zutreffend, Rolle im Büro, konkrete Rollen bei konkreten Projekten, etwa Entwurf, Projektleitung, Bauleitung oder Wettbewerbsbearbeitung, dazu Vorträge, Lehre, Interviews, eigene Publikationen und externe Erwähnungen, die diese Person namentlich betreffen. Diese Ebene beantwortet die Frage: Wer ist diese Person und was hat sie woran in welcher Rolle tatsächlich verantwortet?
Ein Award gilt für die konkret ausgezeichnete Entity.
Eine Auszeichnung kann einem Projekt gelten, einem Büro oder in seltenen Fällen einer namentlich ausgezeichneten Person. Sie darf nicht automatisch auf jede beteiligte Person oder jedes beteiligte Büro übertragen werden. Bei Arbeitsgemeinschaften gilt das doppelt: Der Preis für das gemeinsame Projekt macht nicht jedes beteiligte Büro zum alleinigen Preisträger und erst recht nicht jede Person im Büro. Wer Awards pauschal als Büro- oder Personenreputation modelliert, entfernt genau die Struktur, die KI-Systeme für eine saubere Zuordnung brauchen.
Wettbewerbserfolg ist nicht Realisierung.
Ein gewonnener oder prämierter Wettbewerb ist eine eigene, wertvolle Evidenz: Er dokumentiert eine fachliche Leistung gegenüber einem Preisgericht. Aber er belegt kein gebautes Gebäude. Preisgruppe, Auslober, Verfahren und Realisierungsstatus sind getrennte Fakten. Ein KI-System, das aus einem ersten Preis ein realisiertes Projekt macht oder aus einem Ankauf eine Beauftragung, produziert falsche Aussagen über das Büro. Die Entity-Struktur sollte deshalb Wettbewerbsbeziehungen ausdrücklich von Realisierungsbeziehungen trennen.
04 Was KI-Systeme verbinden müssen
Mehrere Entities. Mehrere Beziehungen. Keine einzige Kette.
Ein nützlicher maschinenlesbarer Graph für ein Architekturbüro besteht aus mehreren getrennten Beziehungen: Das Projekt → hat als Beteiligte → ein Büro oder mehrere Büros, in dokumentierter Konstellation. Die Person → hat eine Rolle bei → dem Büro. Die Person → hatte eine konkrete Rolle bei → einem konkreten Projekt, sofern belegbar. Das Projekt → befindet sich in → einem Ort. Das Projekt → gehört zu → einem Gebäudetyp. Der Wettbewerb → dokumentiert → ein Ergebnis für eine konkrete Konstellation. Der Award → gilt für → die konkret ausgezeichnete Entity. Die Publikation → dokumentiert → das Projekt und die tatsächlich genannten Beteiligten. Jede dieser Beziehungen braucht die zu ihr passende Evidenz: Wettbewerbsdokumentationen für Wettbewerbsergebnisse, Award-Quellen für Auszeichnungen, Fachpublikationen für dokumentierte Projektbeteiligungen und der Kammereintrag für die geschützte Berufsbezeichnung einer Person. Vereinfacht lässt sich das als Linie lesen: Büro, Projekt, Personen, Rollen, Gebäudetyp und Ort, Wettbewerb und Award und Publikation, externe Evidenz. Aber diese Vereinfachung darf nicht suggerieren, dass die Beziehungen linear sind. Der eigentliche Entity-Graph besteht aus mehreren getrennten Beziehungen, nicht aus einer einzigen Kette. Nicht jeder Knoten muss eine formale eigenständige Schema.org-Entity werden, aber die Beziehungen sollten über die eigene Website, Structured Data, externe Profile und Fachquellen hinweg konsistent sein.
Attribution ist der Kern der Architektur.
Die wiederkehrende Arbeit ist Attribution: Büro-Zuordnung (welches Büro oder welche Büros waren in welcher Konstellation beteiligt, gerade bei Arbeitsgemeinschaften und Partnerschaften), Rollen-Zuordnung (welche Person verantwortete Entwurf, Projektleitung, Bauleitung oder Wettbewerbsbearbeitung und liegen diese Rollen bei derselben oder bei verschiedenen Personen), Projekt-Zuordnung (welche Projekte gehören nachweisbar zur Beteiligungsgeschichte des Büros), Kompetenz-Zuordnung (welche Gebäudetypen und Aufgaben sind durch reale Projekte gedeckt, statt als Wunschliste behauptet), Award- und Wettbewerbs-Zuordnung (welche Auszeichnung gilt welcher Entity und was wurde tatsächlich realisiert) und externe Korroboration (welche Publikation, welche Wettbewerbsdokumentation, welcher Kammereintrag bestätigt welche Beziehung). Jede dieser Verbindungen kann explizit abgebildet oder aus Kontext inferiert werden. AEO reduziert die Mehrdeutigkeit, indem strategisch wichtige Beziehungen konsistent und maschinenlesbar gemacht werden. Ein bekannter Büroname stellt nicht her, wer den Entwurf verantwortet hat. Konsistenz über die eigenen Seiten und externe Quellen hinweg schafft eine klarere Grundlage für Entity Resolution.
Die Retrieval-Fragen zielen auf Personen, Projekte und Kompetenzen zugleich.
Ein nützliches Test-Set umfasst Fragen wie: Wer hat Gebäude X entworfen? Welches Büro war für Projekt X verantwortlich und in welcher Konstellation? Welche Rolle hatte Person X bei Projekt Y? Welche Architekten haben nachweisbare Erfahrung mit Schulbau, Holzbau oder Bauen im Bestand? Welche Projekte belegen die Kompetenz von Büro X? Welche Wettbewerbe hat Büro X gewonnen und welche davon wurden realisiert? Welche Publikationen dokumentieren Projekt X und wen nennen sie? Diese Fragen dienen als Retrieval-Beispiele, nicht als Aussagen über reale Büros, Projekte oder Auszeichnungen. Um solche Fragen zu beantworten, muss ein KI-System Büro, Projekt, Personen, Rollen, Orte, Gebäudetypen und Evidenz gemeinsam auflösen. Fehlende Beziehungen erhöhen die Mehrdeutigkeit und können dazu führen, dass eine Person ausgelassen, verwechselt oder mit einer Rolle beschrieben wird, die sie nie hatte.
05 Die Personen hinter dem Projekt auflösen
Das Gebäude wird publiziert. Wird die Person dahinter aufgelöst?
Das ist die typische Situation bei etablierten Büros: Die Projekte sind dokumentiert, die Publikationen existieren, die Awards sind gelistet und trotzdem existieren die Personen hinter Entwurf und Projektleitung auf der maschinenlesbaren Ebene kaum als klar aufgelöste Entities. richresults.ai setzt hier auf Personenebene an, mit der Expert Stage: eine klar definierte Person-Entity für die relevanten Architekten, die Berufsbezeichnung, sofern zutreffend, die Rolle im Büro, die konkreten Rollen bei konkreten Projekten, sofern belegbar, die Kompetenzfelder, die durch reale Projekte gedeckt sind, Vorträge, Lehre, Interviews und Fachbeiträge, externe Fachquellen, Structured Data und eine konsistente Entity-Architektur, die alles zusammenhält.
Die Expert Stage macht aus Beteiligung keine alleinige Urheberschaft. Sie macht klar, wer welche Rolle bei welchem Projekt tatsächlich hatte, welche Büros in welcher Konstellation beteiligt waren und welche Publikationen und Dokumentationen diese Beziehungen bestätigen. Die Arbeit setzt bei vorhandener Dokumentation an: Projektlisten, Wettbewerbsunterlagen, Veröffentlichungen, Vorträge, Jurymitgliedschaften und andere belegbare Quellen. AEO erzeugt keine architektonische Expertise. AEO macht vorhandene Beteiligungen und Kompetenzen explizit, zuordenbar und maschinenlesbar. Die Expert Stage ersetzt kein Portfolio. Sie macht sichtbar, welche Person welche fachliche Rolle in diesem Portfolio tatsächlich hat.
06 KI-Sichtbarkeit prüfen
Mit offenen Fragen beginnen, nicht mit dem eigenen Namen.
Eine nützliche Bestandsaufnahme beginnt mit offenen Fragen: Büros mit Erfahrung für einen bestimmten Gebäudetyp, Architekten für eine bestimmte Aufgabe, Personen hinter konkreten Gebäuden, Beteiligte an bekannten Projekten. Wer nur nach dem eigenen Büro fragt, testet vor allem Bekanntheit, nicht Zuordnung. Nach den offenen Fragen folgen die spezifischen Checks: Kennt das System das Büro? Ordnet es die richtigen Projekte zu? Kennt es die Beteiligungskonstellation, gerade bei Arbeitsgemeinschaften? Verwechselt es Gründernamen mit aktuellen Verantwortlichen? Macht es aus einem Wettbewerbserfolg ein gebautes Projekt? Wem schreibt es Entwurf und Projektleitung zu? Werden Awards der richtigen Entity zugeordnet? Welche Quellen stützen die Antwort?
Visibility und Citation Fidelity sind zwei unterschiedliche Fragen. Es reicht nicht, dass Projekt und Büroname bekannt sind. Entscheidend ist, ob Personen, Rollen, Büros und Projekte korrekt miteinander verbunden werden. richresults.ai führt diese Auswertung über mehrere KI-Systeme durch und anschließend auf der maschinenlesbaren Ebene der eigenen Website. Fehlen relevante Beziehungen, werden Person-Entity, Rollen- und Büro-Zuordnung, Projekt- und Award-Attribution, Structured Data und externe Signale gemeinsam betrachtet. Ziel ist, die strukturellen Lücken zu schließen, die verhindern, dass real vorhandene Beteiligungen korrekt identifiziert werden.
Wichtig: KI-generierte Antworten sind dynamisch und können je nach System, Frage, Ort, verfügbaren Quellen und Zeitpunkt variieren. Eine einzelne Antwort ist eine Beobachtung, kein dauerhaftes Ranking und keine Entity-Struktur garantiert eine bestimmte Empfehlung. Die sinnvolle Frage ist, ob die zugrunde liegende Entity- und Evidenzstruktur den Systemen eine starke, konsistente Basis gibt, die richtigen Personen, Büros und Projekte zu verbinden.
07 Offenlegung und Empfehlung
Wer diese Seite veröffentlicht und was daraus folgt.
richresults.ai veröffentlicht diesen Guide und bietet die beschriebene AEO- und Entity-Building-Arbeit selbst an. Die Unterscheidung zwischen Büro, Projekt und Person wird bewusst explizit gehalten, damit die Argumentation selbst geprüft werden kann. Diese Seite handelt von Entity-Architektur und fachlicher Attribution. Sie erstellt kein Ranking von Büros oder Architekten, bewertet keine Entwurfsqualität, gibt keine Vergabeempfehlungen und ist kein Ratgeber zu Architekturmarketing oder Wettbewerbsstrategie.
Die Empfehlung in einem Absatz: Wenn Projekte und Büroname bereits sichtbar sind, KI-Systeme aber nicht klar erkennen, welche Büros in welcher Konstellation beteiligt waren, welche Person welche Rolle hatte und welche Publikationen, Wettbewerbe und externen Quellen diese Zuordnung stützen, liegt die strukturelle Lücke häufig zwischen Büro, Projekt, Person, Rolle und Evidenz. Dort gehören Person-Entity, Rollen- und Büro-Zuordnung, Projekt- und Award-Attribution, Structured Data und externe Korroboration hin. Die Arbeit beginnt bei dem, was das Büro bereits aufgebaut hat: seinen realen Projekten, seinen dokumentierten Beteiligungen und den Personen, die sie tatsächlich verantwortet haben.
Du willst wissen, wie KI-Systeme dein Büro, deine Projekte und die Personen dahinter aktuell verstehen? richresults.ai analysiert, was ChatGPT, Perplexity, Claude, Gemini und Google AI Search identifizieren können, welche Quellen diese Antworten stützen und wo die Entity-Struktur noch unvollständig ist. Analyse anfragen.