Getty Images/iStockphoto
Warum Context Engineering in Unternehmen immer wichtiger wird
Da Unternehmen KI-Agenten in ihren Geschäftssystemen einsetzen, entwickelt sich Context Engineering zu einer entscheidenden Disziplin für Governance und Rentabilität.
Context Engineering gewinnt zunehmend an Bedeutung, da Unternehmen KI – insbesondere agentische KI – in ERP-, CRM-, HR- und Collaboration-Plattformen integrieren. Auf einer übergeordneten Ebene handelt es sich um eine Neugestaltung des traditionellen Datenmanagements für das Zeitalter der KI und agentischer Systeme. Der große Wandel besteht nun in der wachsenden Erkenntnis, dass Ontologie – also die Beziehung und Bedeutung der Daten – entscheidend für die Realisierung des ROI bei allen KI-Projekten wird.
Im Kern ist Context Engineering die Disziplin, die darauf abzielt, die Bedeutung von Unternehmenssystemen – und nicht nur deren Daten – den Prozessen zur Verfügung zu stellen, die sie benötigen. Datenarchitekten verfolgen dieses Ziel seit Jahrzehnten, jedoch mit begrenzten Ergebnissen oder einer geringen Akzeptanz. Nun entdecken Unternehmen jedoch, dass fragmentierte Kontexte den Nutzen von KI-Anwendungen einschränken. Auch neu entstehende KI-Modelle und -Prozesse können dazu beitragen, diese Lücken zu schließen.
Entwickler von KI-Systemen nutzen diese Techniken, um die Zusammenführung der richtigen Daten für eine bestimmte Abfrage oder einen bestimmten Prozess zu optimieren und gleichzeitig Token-Budgets zu verwalten. Zudem muss das richtige Gleichgewicht zwischen der Flexibilität probabilistischer großer Sprachmodelle und der Geschwindigkeit sowie Genauigkeit deterministischer Unternehmenssysteme gefunden werden.
Investitionen in neue KI-Tools lösen nur einen Teil des Problems. Ameet Ubhayaker, Director of Enterprise Data Analytics and AI bei Protiviti, sagt: „Führungskräfte erkennen mittlerweile, dass sie KI-Modelle kaufen können, aber den Kontext selbst aufbauen müssen.“ Diese Arbeit war zuvor in Data-Engineering-Tickets verborgen. Dies zusammenzuführen bedeutet, strategische Richtlinien für Datendefinitionen, Entitätsauflösung und Zugriffsrichtlinien als strategische KI-Abhängigkeit zu entwickeln.
Context Engineering vereint das relativ neue Prompt Engineering mit älteren Disziplinen des Stammdatenmanagements (Master Data Management, MDM). Prompt Engineering entstand mit KI-Chatbots, um die Art und Weise zu verbessern, wie ein generatives KI-Modell Anweisungen interpretiert. Stammdatenmanagement und semantisch basierte Ontologien unterstützen dabei, einen kanonischen Datensatz darüber zu erstellen, was Geschäftseinheiten und -beziehungen bedeuten, zusammen mit Prozessen, um diese in Datenintegrationspipelines zu kodieren.
Hugh Mulligan, Associate Director of Cyber Risk and Governance bei S-RM, verweist darauf, dass es bei dieser Disziplin „hauptsächlich darum geht, alte Prinzipien unter neuen Einschränkungen anzuwenden“.
Wachsende Priorität in Unternehmen
Zwei aktuelle Trends machen Context Engineering zu einer wachsenden Priorität in Unternehmen. Erstens werden Agenten zu einer neuen Art von Konsumenten für Unternehmensdaten. Zweitens helfen neue KI-Techniken dabei, bisher manuelle Prozesse zur Erstellung von Kontextgraphen zu automatisieren.
Dr. Adnan Masood, Chief AI Architect beim Digitaldienstleister UST, sagt, wenn die Unternehmensleitung Context Engineering zur Priorität erklärt, werde die Zuständigkeit weniger willkürlich. Er habe schon Räume betreten, in denen drei verschiedene Definitionen von „aktivem Kunden“ fest in drei verschiedenen Agenten programmiert waren, die von drei verschiedenen Teams geschrieben wurden – von denen keines wusste, dass die anderen existieren. Die wichtigste Erkenntnis ist, dass der Zugriff auf Rohdaten noch kein Kontext ist. Viele Unternehmen stellen Agenten eine Datenbankverbindung zur Verfügung und betrachten die Sache damit als erledigt. „Das ist so, als würde man einen Analysten einstellen, ihm einen SQL-Zugang geben und ihm nie sagen, was das Unternehmen eigentlich macht“, witzelte Masood.
Die traditionelle Dateninfrastruktur wurde darauf ausgelegt, durch Analysen in Tabellenkalkulationen, Dashboards und Präsentationen einen Mehrwert zu liefern. Agenten benötigen eine andere Art von Dateninfrastruktur, die Beziehungen, Aktualitätssignale und Herkunft aufzeigt. Sie müssen nicht nur wissen, wie der Status eines Kunden ist, sondern auch, wie dieser zustande kam und welche Compliance-Prozesse befolgt werden müssen, wenn sie auf der Grundlage dieser Informationen handeln. Eine grundlegende Herausforderung besteht darin, dass verschiedene Prozesse im Zusammenhang mit Context Engineering über verschiedene Abteilungen und Disziplinen hinweg verteilt sein oder in Schatten-KI-Projekten verborgen sein können.
Wem gehört der Unternehmenskontext?
Da KI-Agenten zunehmend über ERP-, CRM-, HR- und Collaboration-Plattformen hinweg agieren, erkennen Unternehmen, dass die Verantwortung für den Kontext eine gemeinsame Unternehmenskompetenz ist, die sowohl eine zentralisierte Steuerung als auch eine dezentrale Verantwortlichkeit erfordert.
In vielen Unternehmen ist der CIO oder Chief Data Officer für die Überwachung der übergeordneten Strategie zuständig. Dazu gehören die Festlegung von Standards und Steuerungsmodellen, die Gewährleistung semantischer Konsistenz sowie die plattformübergreifende Koordination. Letztendlich sind es jedoch die Führungskräfte, die die Bedeutung hinter den Unternehmensdaten definieren und festlegen, was Begriffe wie „aktiver Kunde“, „risikoreicher Lieferant“ oder „produktiver Mitarbeiter“ innerhalb des Unternehmens bedeuten.
Teams für Unternehmensarchitektur, Data Governance und Plattformen setzen diese Definitionen mithilfe von Metadatenstrukturen, Integrationsregeln, Identitätszuordnungen und Richtlinienkontrollen in funktionierende Systeme um. Gleichzeitig übernehmen Produkt- und KI-Teams zunehmend die Verantwortung für die Kontextqualität innerhalb spezifischer Workflows und Agenten. Dazu gehören die Verwaltung der Abruflogik, die Durchsetzung von Richtlinien und die Messung, ob Agenten tatsächlich die Geschäftsergebnisse verbessern.
Die größte Herausforderung ist eher organisatorischer als technischer Natur. Da KI-Systeme anwendungs- und abteilungsübergreifend eingesetzt werden, sollten Unternehmen den Kontext nicht nur als Nebenprodukt von Software betrachten, sondern als gemeinsame operative Infrastruktur, die eine kontinuierliche Governance, Rechenschaftspflicht und Aufsicht durch die Geschäftsleitung erfordert.
Die systemübergreifende Lücke
Alle großen Unternehmenssoftwareplattformen für Customer Relationship Management (CRM), Enterprise Resource Planning (ERP) und Personalmanagement machen Fortschritte beim Aufbau des zugrunde liegenden Wissensgraphen, um das Kontextmanagement innerhalb ihrer Ökosysteme zu verbessern. Laut Masood treten Probleme in dem Moment auf, in dem ein Mitarbeiter die Grenzen eines Anbieters überschreitet.
Beispielsweise kann ein Agent im Revenue Operations gleichzeitig und innerhalb eines einzigen Zyklus Zugriff auf eine Salesforce-Pipeline, den SAP-Bestand, die Verhaltenshistorie in Snowflake und die Metrikdefinitionen von dbt Labs benötigen. „Kein Anbieter wird Identität, Semantik und Richtlinien über seine drei größten Konkurrenten hinweg harmonisieren“, sagt Masood.
Dies kann zu peinlichen Problemen führen. Masood arbeitete beispielsweise mit einem globalen Industrieunternehmen zusammen, dessen Salesforce-Mitarbeiter lediglich Einblick in den Kundendatensatz mit einem bevorstehenden Verlängerungsdatum hatte und eine fröhliche Verlängerungs-E-Mail versandte. Unterdessen hatte derselbe Kunde in SAP eine offene Compliance-Sperre und einen festgefahrenen Container, beides Probleme, die der CFO 48 Stunden zuvor persönlich eskaliert hatte. Der CFO des Kunden leitete die fröhliche, von Salesforce generierte E-Mail an den CEO des Anbieters weiter, mit einer einzigen Zeile: „Ist das ein Witz?“ Diese eine E-Mail war der Startschuss für ein großes systemübergreifendes Kontextarchitekturprogramm beim Anbieter.
Probleme im Zusammenhang mit Context Engineering können auch auftreten, wenn dasselbe in verschiedenen Systemen unterschiedliche Bedeutungen hat. „Technisch gesehen bricht die Logik an den ‚semantischen Nähten‘ zusammen, wo Definitionen systemübergreifend voneinander abweichen“, sagt Ubhayaker.
In der Gesundheitsbranche kann ein Mitarbeiter beispielsweise Arzneimitteldaten korrekt abrufen, aber nicht zwischen zugelassenen und in der Erprobung befindlichen Indikationen unterscheiden. In diesem Szenario kann ein Fehler eher zu einem Compliance-Verstoß als zu einer falschen Antwort führen.
Ähnlich sieht Ubhayaker Fehler bei der Entitätsauflösung in Personalmanagement- oder CRM-Umgebungen. Ein Agent, der ein Bewerbermanagementsystem und ein HR-Informationssystem abfragt, kann einen „Bewerber“ und einen „Mitarbeiter“ als zwei verschiedene Personen behandeln – oder schlimmer noch, sie falsch zusammenführen. Die Erkenntnis daraus ist, dass es bei fehlendem Kontext selten um Rohdaten geht, sondern vielmehr um Geschäftssemantik.
Aufbau einer Context-Engineering-Kompetenz
Context Engineering muss als strategische Kompetenz betrachtet werden und nicht als einmaliges Tool oder Verfahren. Das bedeutet, dass CEOs und CFOs Budgets, Ausschreibungen und die Programmleitung aufeinander abstimmen müssen. Zu langsames Vorgehen kann KI-Projekte aushungern oder neue Probleme schaffen, aber auch zu schnelles Vorgehen birgt Risiken.
Ein guter Ausgangspunkt ist das Investitionsverhältnis. Die Angst, den KI-Zug zu verpassen, hat dazu geführt, dass KI-Ausgaben für Rechenleistung und Modellzugang priorisiert werden. Dies muss durch ergänzende Investitionen in Context Engineering ausgeglichen werden, wodurch die Kosten für die Modellinferenz erheblich gesenkt und die Leistung in Produktionssystemen verbessert werden können.
Masood hat beobachtet, dass diszipliniertes Context Engineering die Inferenzkosten um das Zehnfache und die Latenz um das Vierfache senkt. „Die Einsparungen liegen im Rahmen, nicht im Modell“, sagt er. „CFOs müssen in die Infrastruktur investieren.“
Ausschreibungen für die Beschaffung von KI sollten auch Diskussionen über Context Engineering und verwandte Themen beinhalten. Laut Mulligan konzentrieren sich die meisten heutigen KI-Ausschreibungen in der Regel auf die Modellleistung und die Integrationstiefe. Sie sollten auch fragen: Legt der Anbieter offen, welchen Kontext das Modell verwendet? Können Sie Ihre eigenen Abruf- und Datenquellen einbringen? Wo befindet sich die Kontextebene tatsächlich – bei Ihrem Mandanten oder bei dem Anbieter? Wie sieht der Migrationspfad aus, wenn Sie sich entscheiden, zu wechseln? Mulligan hat bei seiner Arbeit mit Beschaffungsteams noch keine Ausschreibungen gesehen, die diese Fragen beantworten.
Die Festlegung des Umfangs sei eine weitere häufig übersehene Dimension, fügt er hinzu. „KI-Initiativen konzentrieren sich in der Regel auf die Frage ‚Diese Fähigkeit selbst entwickeln oder kaufen?‘ mit Kennzahlen zur Akzeptanz“, sagt er. „Die Arbeit, die darüber entscheidet, ob diese Fähigkeit tatsächlich funktioniert, wird oft als bereits vorhanden vorausgesetzt.“
„Wir sehen Erfolge nicht in ‚Kontextausschüssen‘, sondern bei Datenproduktmanagern“, sagt Ubhayaker. Diese Personen sind für das Endergebnis verantwortlich: den Agenten, die von ihm verarbeiteten Daten, die Zugriffsrichtlinien und die Bewertungskennzahlen. Der Kontext sollte keine eigenständige Abteilung sein; er sollte das Bindeglied innerhalb eines Produktteams sein.
Ubhayaker warnt zudem davor, dass Untätigkeit wahrscheinlich dazu führt, dass KI-Initiativen nie über die Pilotphase hinauskommen. Ohne Context Engineering produzieren Agenten in großem Maßstab „plausibel falsche“ Ergebnisse, was zu einem sich verstärkenden Reputationsverlust führt, der oft nicht mehr rückgängig zu machen ist. Es ist auch wichtig, sich vor einer übertriebenen Begeisterung für Context Engineering zu hüten, da dies zu einer Kontextbürokratie führen kann. „Context Engineering sollte eine unterstützende Funktion sein: ein Weg, um geschäftsrelevante Artefakte schneller bereitzustellen, und kein Ziel an sich“, sagt Ubhayaker.
Dieser Artikel ist im Original in englischer Sprache auf Search ERP erschienen.
