KI-Agenten für Unternehmen: Was OpenAI Presence wirklich bietet
OpenAI Presence ist kein Agenten-Baukasten, sondern ein betreutes Enterprise-Deployment. Was es leistet, für wen es passt und welche Kennzahlen zählen.
OpenAI zufolge bearbeitet Presence inzwischen 75% der eingehenden Anliegen auf der englischsprachigen Support-Hotline ohne menschliche Hilfe. Seine Optimierungsschleife senkte zudem die Übergaben an Mitarbeitende innerhalb von 10 Tagen um 15 Prozentpunkte. Hinter diesen Zahlen steht jedoch kein KI-Agenten-Baukasten, für den man sich einfach anmelden kann. Presence ist ein betreutes Enterprise-Deployment, das Agent, Richtlinien, Evaluationen, Systemintegration und den laufenden Betrieb bündelt.
Das Urteil: Presence verkauft das KI-Agenten-Deployment, nicht das Modell
OpenAI Presence ist eine erwägenswerte Option, wenn ein Sprach- oder Chatprozess mit Kundenkontakt unter strikten Richtlinien echte Aktionen ausführen soll und OpenAI einen Teil der Verantwortung für die Bereitstellung übernehmen soll. Für kleine Teams auf der Suche nach einem Agenten-Baukasten zur Selbstbedienung, für Entwickler mit SDK-Bedarf oder für Unternehmen ohne einen klar abgegrenzten Zielprozess ist Presence dagegen der falsche Ausgangspunkt.
Die Bedingungen zum Marktstart sind ungewöhnlich aufschlussreich: Presence steht nur geeigneten Unternehmenskunden im Rahmen einer begrenzten allgemeinen Verfügbarkeit offen. Forward Deployed Engineers von OpenAI und ausgewählte globale Systemintegratoren leiten die Implementierungen; zugleich stellt OpenAI ausdrücklich klar, dass das Produkt nicht als Self-Service angeboten wird. Weder auf der Launch-Seite noch auf der aktuellen Frontier-Seite findet sich ein öffentlicher Listenpreis.
Damit ist das Bereitstellungsmodell selbst das eigentliche Produkt. Ein leistungsfähiges Modell kann eine Supportanfrage bereits einordnen. Schwierig wird es dort, wo der richtige Kontokontext bereitgestellt, Berechtigungen begrenzt, Erstattungsregeln durchgesetzt, Aktionen validiert, Freigabepflichten erkannt, riskante Fälle an Menschen weitergeleitet und Systeme aktualisiert werden müssen, ohne das Verhalten vom Vortag zu beschädigen. Presence bündelt all diese Aufgaben in einem betreuten Gesamtprojekt.
Was OpenAI Presence tatsächlich umfasst
Presence bildet einen produktionsreifen Rahmen um eine klar definierte Aufgabe und keinen universellen digitalen Mitarbeiter. Jede Implementierung beginnt mit einem konkreten Workflow. Der Agent erhält ausschließlich das Wissen und die Systemzugriffe, die er dafür braucht; Richtlinien, Freigabepunkte und Regeln für die Übergabe an Menschen legt das Unternehmen fest.
Der Begriff Guardrail klingt leicht nach einem Filter, der erst nach der Modellantwort greift. Bei Presence bezeichnet er ein umfassenderes Kontrollsystem: Regeln begrenzen Eingaben, Tools, Aktionen, Berechtigungen und Eskalationen. Dafür verbindet Presence Richtlinien und Standardarbeitsanweisungen mit Guardrails, genehmigten Aktionen, Simulationen, Evaluationswerkzeugen und einem durch Codex gestützten Verbesserungsprozess.
Eine Aufgabe klar abgrenzen
Ausgangspunkt ist ein vollständiges Ergebnis, etwa die Klärung eines Abrechnungsproblems, die Unterstützung bei einem Versicherungsfall oder die Bearbeitung einer IT-Anfrage von Mitarbeitenden. Eine breite Vorgabe wie „allen Kunden helfen“ liefert weder einen brauchbaren Evaluationsdatensatz noch eine belastbare Berechtigungsgrenze.
Kontext und Zugriffe begrenzen
Angebunden werden nur die Datensätze und Systeme, die für diese Aufgabe erforderlich sind. Ein Abrechnungsagent kann Identitäts-, Konto-, Rechnungs- und Zahlungsdaten benötigen. Uneingeschränkter Zugriff auf den gesamten Kundendatenbestand ist dafür nicht nötig.
Richtlinien und Freigaben kodifizieren
Festgelegt wird, was der Agent beantworten darf, welche Aktionen zulässig sind, wann eine Freigabe erforderlich ist und wann ein Mensch übernimmt. Ein korrekter Satz in Verbindung mit einer nicht autorisierten Aktion bleibt ein Produktionsfehler.
Vor dem Start simulieren
Häufige Anfragen, Grenzfälle und Szenarien mit höherem Risiko werden mithilfe von Gradern getestet. Laut OpenAI prüfen sie Ergebnisqualität, Richtlinientreue, Tool-Nutzung und Eskalationsverhalten.
Unter Änderungskontrolle verbessern
Produktivsitzungen, Eskalationen und Qualitätssignale machen Lücken sichtbar. Codex untersucht diese Signale und schlägt Änderungen vor, die ein Team gegen die Produktivversion testen kann, bevor es eine kontrollierte Einführung freigibt.
Dieser Kreislauf ist wichtiger als die Demo. Ein Voice Agent kann am ersten Tag natürlich klingen und trotzdem scheitern, sobald sich ein Produkt ändert, eine neue Ausnahme bei Erstattungen gilt oder Anrufende Formulierungen finden, die im ursprünglichen Testdatensatz fehlten. Presence behandelt das Produktivverhalten als Quelle für Änderungsvorschläge und schaltet Tests und Freigaben zwischen Vorschlag und Livesystem.
Für Verantwortliche im KI-Kundenservice liegt genau darin der praktische Unterschied zwischen einem Chatbot und einem Betriebssystem für einen Workflow. Ein Chatbot antwortet. Ein Produktivagent verifiziert, entscheidet, handelt innerhalb seiner Befugnisse, protokolliert den Vorgang und übergibt, sobald das Risiko seine Befugnisse überschreitet.
Die Belege sind vielversprechend, aber eng begrenzt
Die zum Start veröffentlichten Daten zeigen, dass Presence einen echten Supportkanal betreiben kann. Einen allgemeinen wirtschaftlichen Nutzen für Unternehmen belegen sie noch nicht. OpenAI meldet die Ergebnisse aus der eigenen englischsprachigen Support-Hotline unter 1-888-GPT-0090. Damit sind die Zahlen zugleich aussagekräftige Produktdaten und Angaben des Anbieters.
Die Liste der Entwicklungspartner befindet sich in einem früheren Stadium. BBVA prüft Sprachsupport für alltägliche Bankanliegen in Mexiko. SoftBank testet natürlich wirkende Kundengespräche auf Japanisch. IAG untersucht Unterstützung bei Nachfragespitzen, etwa während Unwettern. Diese Programme zeigen eine gewisse Bandbreite bei Sprachen und regulierten Abläufen, doch OpenAI stellt sie nicht als gleichwertige Produktionsergebnisse dar.
Außerdem fehlen beim Marktstart genau die Zahlen, die ein Einkaufsteam benötigt: öffentliche Preise, Implementierungsdauer, Mindestvolumen, Supportmodell, Fehlerquoten nach Aktion und Kosten pro korrekt gelöstem Kontakt. Angesichts der begrenzten allgemeinen Verfügbarkeit ist das nachvollziehbar. Dennoch existiert damit noch kein glaubwürdiger öffentlicher Kostenvergleich. Präzise ROI-Aussagen ohne Vertrag und Ausgangswerte des Workflows sollten Käufer als Fiktion behandeln.
Presence besetzt eine Ebene im Agenten-Stack von OpenAI
Presence ist innerhalb einer Produktfamilie, zu der auch ChatGPT Workspace Agents, das OpenAI Agents SDK und Frontier gehören, der betreute Weg für konkrete Workflows. Wer diese Angebote für austauschbar hält, startet einen fehlerhaften Beschaffungsprozess, denn bei jedem liegt die Verantwortung an einer anderen Stelle.
ChatGPT Workspace Agents: wiederkehrende interne Arbeit
ChatGPT Workspace Agents sind der schlankere Weg für wiederkehrende Aufgaben, die bereits in einem Business- oder Enterprise-Workspace stattfinden. Ersteller können Modell und Reasoning-Aufwand wählen, Apps und Tools verbinden, den Agenten für Kollegen freigeben, ihn in Slack einsetzen, zeitgesteuert ausführen oder über eine API anstoßen.
Die Kontrollen sind relevant, der Ausführungsrahmen ist jedoch enger. Schreibaktionen für Apps und Connectoren stehen standardmäßig auf Immer fragen. Connector Action Constraints können festlegen, was eine Integration tun darf; OpenAI weist allerdings darauf hin, dass diese Einschränkungen nicht die Daten filtern, die ein Connector zurückliefert. Pro Datei gilt ein Limit von 512 MB, insgesamt sind pro Agent 10 GB erlaubt.
Die entscheidende API-Grenze betrifft den Betrieb: Ein Trigger stellt einen Run in die Warteschlange und antwortet mit 202 Accepted, jedoch ohne Response Body. Eine Run-ID wird nicht ausgegeben, und das Ergebnis lässt sich derzeit über diese API nicht abrufen. Für interne Fire-and-forget-Aufgaben kann das ausreichen. Für ein kundenorientiertes Produkt, das synchronen Status, Wiederholungslogik und ein nachvollziehbares Ergebnis benötigt, ist es ein schwacher Vertrag.
OpenAI Agents SDK: Verantwortung für das eigene Produkt
Der Weg über das OpenAI Agents SDK passt zu Unternehmen, die den Agenten in ihrem eigenen Produkt oder ihrer eigenen Infrastruktur betreiben wollen. OpenAIs Leitfaden für die Agentenentwicklung verdichtet die Architektur auf drei Kernkomponenten: ein schlussfolgerndes Modell, lesende oder handelnde Tools und Anweisungen, die das Verhalten bestimmen.
Diese Komponenten bilden lediglich den Kern des Systems. Identität, Autorisierung, Tool-Verträge, Evaluationsdaten, Monitoring, Ausweichverhalten, Störfallreaktion und Kosten bleiben Aufgabe des Entwicklungsteams. OpenAI empfiehlt, zunächst mit dem leistungsfähigsten Modell eine Evaluationsbasis zu schaffen und es anschließend dort durch kleinere Modelle zu ersetzen, wo die Genauigkeit ausreichend bleibt. Ebenso lautet die Empfehlung, zuerst einen einzelnen Agenten auszureizen, bevor eine Multi-Agenten-Architektur hinzukommt.
Eine Eigenentwicklung ist richtig, wenn der Workflow das Produkt differenziert, ungewöhnliche Bereitstellungsbedingungen gelten oder Modell- und Tool-Kosten granular optimiert werden müssen. Soll Anbieterportabilität erhalten bleiben, muss die Abstraktion oberhalb des SDK eines einzelnen Anbieters liegen. Allein die Entscheidung für ein SDK schafft noch keine Portabilität.
OpenAI Frontier: die unternehmensweite Plattform
OpenAI Frontier ist der umfassende Plattformweg für Unternehmen, die viele Agenten über Abteilungen und Systeme hinweg betreiben. Die veröffentlichten Ebenen umfassen Business Context, Agent Execution, Evaluation und Optimierung sowie Sicherheit und Governance für Unternehmen.
Frontier soll kundeneigene Agenten, OpenAI-Agenten und Agenten von Drittanbietern auf einer Plattform steuern. OpenAI beschreibt Identitäts- und Zugriffsmanagement für Agenten, eindeutige Berechtigungen, auditierbare Aktionen, Monitoring und detaillierte Protokolle. Im Enterprise Frontier Program arbeiten außerdem Forward Deployed Engineers mit dem Kunden an der Architektur, operationalisieren die Governance und führen Agenten in den Produktivbetrieb.
Die praktische Produktlandkarte ist übersichtlich: Workspace Agents bündeln die interne Agentenerfahrung, das SDK liefert Bausteine, Presence liefert einen implementierten Workflow und Frontier die unternehmensweite Steuerungsebene. OpenAI hat keine öffentliche Vertragsübersicht veröffentlicht, aus der hervorgeht, welche Frontier-Komponenten in einem Presence-Projekt enthalten sind. Käufer sollten deshalb nachfragen, statt Annahmen zu treffen.
Für einen breiteren Marktvergleich jenseits von OpenAI lohnt sich ein Blick auf Unternehmensplattformen und betriebliche Abwägungen in die besten KI-Agenten für 2026.
Wer Presence kaufen sollte – und wer selbst entwickeln sollte
Presence eignet sich, wenn der Workflow eng umrissen, wertvoll, aktionsorientiert und bei Fehlern teuer ist. Eine Eigenentwicklung ist vorzuziehen, wenn der Agent strategisches geistiges Eigentum darstellt, ungewöhnliche Betriebsbedingungen gelten oder langfristige Kontrolle wichtiger ist als ein betreuter Weg in die Produktion.
Besonders glaubwürdig wirkt Presence bei richtlinienintensiven Serviceabläufen. Ein Beispiel ist ein Versicherer, der während Unwettern Anrufe zum Bearbeitungsstand von Schäden entgegennimmt. Der Agent muss den Anrufer identifizieren, die richtige Police und den passenden Schaden abrufen, eine reine Statusfrage von einem Änderungswunsch unterscheiden, ausschließlich im eigenen Befugnisrahmen handeln und den Fall bei steigendem Risiko an einen Menschen übergeben. Natürliche Sprache ist dabei nur ein Baustein. Zugriffsrechte und Eskalation bestimmen, ob der Workflow sicher ist.
Eine Eigenentwicklung gewinnt, wenn der Agent selbst Wettbewerbsvorteile schafft. Ein Anbieter branchenspezifischer Software benötigt womöglich proprietäre Tools, einen domänenspezifischen Evaluationsdatensatz, eine eigene Nutzererfahrung, mehrere Modellanbieter oder eine Bereitstellung in einer Umgebung, die ein Managed Service nicht abdecken kann. Wer den Betriebskreislauf auslagert, kann in diesem Fall zugleich Erkenntnisse auslagern, die im Produktteam bleiben sollten.
Aus Betreibersicht fällt die Antwort je nach Rolle anders aus. Der CTO eines mittelständischen Unternehmens mit einer richtlinienintensiven Supportwarteschlange und ohne Interesse am Aufbau einer dauerhaften Agentenbetriebsfunktion hat einen plausiblen Grund für einen Presence-Pilotversuch. Ein finanzierter Gründer, dessen Produkt der Agent selbst ist, sollte Architektur und Evaluationsdaten in der Regel selbst besitzen. Für leitende Verantwortliche, die interne Freigaben automatisieren, sind Workspace Agents oder ein deterministischer Workflow der bessere Startpunkt. Einzelne technische Entwickler sind mit dem SDK besser bedient, weil Presence weder Self-Service noch als leichtgewichtiges Experiment gedacht ist.
Ein Agent ist nicht allein deshalb sinnvoll, weil ein LLM die Eingabe versteht. Kann eine Regel-Engine zuverlässig entscheiden und erfasst die Sprachschicht lediglich strukturierte Felder, sollte die Entscheidung deterministisch bleiben. Probabilistisches Schlussfolgern gehört nur dorthin, wo echte Mehrdeutigkeit es erfordert.
Vor Vertragsabschluss ist eine Workflow-Scorecard Pflicht
Ein Pilotprojekt sollte an korrekten Ergebnissen und kontrolliertem Scheitern gemessen werden – nicht daran, wie menschlich das Gespräch klingt. Die Lösungsquote von 75% ist eine griffige Überschrift. Im Vertrag braucht es jedoch Definitionen, die der Prüfung durch Finanzen, Risiko und Betrieb standhalten.
Mindestens diese Kennzahlen gehören auf die Scorecard:
- Quote korrekter Lösungen: Anteil der zulässigen Kontakte, die tatsächlich korrekt abgeschlossen wurden, nicht bloß ohne menschliche Beteiligung geschlossen.
- Scheinlösungsquote: Kontakte, die trotz falscher Antwort, falscher Aktion oder ungelöstem Anliegen als erledigt markiert wurden.
- Richtlinientreue: Ob der Agent die zum jeweiligen Zeitpunkt geltenden Regeln und Freigabewege eingehalten hat.
- Qualität der Tool-Ausführung: Ob Lese- und Schreibvorgänge den richtigen Datensatz trafen, korrekte Parameter verwendeten und die beabsichtigte Zustandsänderung bewirkten.
- Qualität der Eskalation: Ob riskante oder unklare Fälle mit dem für die Weiterbearbeitung nötigen Kontext bei der richtigen Person ankamen.
- Kosten pro korrekt gelöstem Kontakt: Vertrags-, Modell-, Integrations-, Prüf- und Supportkosten geteilt durch verifizierte erfolgreiche Ergebnisse.
- Latenz und Abbruchquote: Wie sich die Antwortzeit bei normaler und hoher Nachfrage verhält und ob Anrufende vor einer Lösung auflegen.
- Änderungssicherheit: Ob eine vorgeschlagene Richtlinien- oder Prompt-Änderung die Zielfälle verbessert, ohne bereits etablierte Fälle zu verschlechtern.
Entscheidend ist der Nenner. Ein System kann die Automatisierungsquote steigern, indem es einfache Anfragen übernimmt und alle teuren Fälle eskaliert. Ebenso kann es die Lösungsquote künstlich erhöhen, indem es Gespräche beendet, die später erneut geöffnet werden. Ergebnisse müssen deshalb nach Anliegen, Aktionstyp, Risikoklasse, Sprache und Kanal segmentiert werden, damit teure Fehler nicht im Gesamtwert verschwinden.
Ein vollständiges Ergebnis wählen
Die Aufgabe wird geschäftlich definiert: Wo beginnt sie, wie sieht ein korrekter Abschluss aus, welche Aktionen sind erlaubt und was muss immer an einen Menschen gehen?
Den Evaluationsdatensatz aufbauen
Reale Richtliniendokumente und bereinigte historische Muster decken normale Anfragen, Mehrdeutigkeit, fehlende Informationen, gegnerische Formulierungen, geänderte Richtlinien und risikoreiche Grenzfälle ab.
Die Befugnismatrix festlegen
Jede Tool-Aktion wird nach Reversibilität, Berechtigung, finanzieller Auswirkung und möglichem Kundenschaden eingestuft. Risikoreiche oder irreversible Aktionen bleiben unter menschlicher Aufsicht, bis die Daten eine weitere Grenze rechtfertigen.
Parallel zum bestehenden Prozess testen
Vorgeschlagene Antworten, Aktionen und Eskalationen werden mit dem bestehenden Betrieb verglichen, bevor der Agent Live-Datensätze verändern darf. Abweichungen sind zu untersuchen, nicht durch Mittelwertbildung zu verwischen.
Nach verifiziertem Anliegen erweitern
Bewährte Anfragearten gehen in kontrollierten Gruppen in Produktion. Ein sofortiger Rollback-Pfad bleibt erhalten; Änderungen an Richtlinien, Tools oder Anweisungen benötigen vor der Auslieferung Regressionstests.
Auch die Verantwortlichkeiten müssen vor dem Start geklärt sein. Jemand muss Richtlinienänderungen freigeben, Vorfälle prüfen, Integrationen pflegen, den Evaluationsdatensatz verantworten und entscheiden, wann der Befugnisrahmen des Agenten wächst. Presence kann Technologie und Implementierungskompetenz liefern. Die Verantwortung des Unternehmens für den Workflow nimmt es nicht ab.
Die strategische Einordnung
OpenAI Presence ist relevant, weil sich das Angebot für Unternehmensagenten vom Modellzugang hin zur operativen Verantwortung verschiebt. Das Versprechen lautet nicht mehr „Nutzen Sie unsere Intelligenz“, sondern „Lassen Sie uns gemeinsam einen kontrollierten Workflow betreiben und ihn nach dem Start verbessern“.
Das ist eine stärkere Produktform als ein weiterer allgemeiner Agenten-Baukasten. Gleichzeitig vertieft sie die Abhängigkeit von OpenAIs Implementierungsteam, Modellen, Verbesserungsprozess und Vertrag. Der Tausch ist sinnvoll, wenn betreute Geschwindigkeit und geteilte Betriebserfahrung wertvoller sind als der Besitz des Systems. Er wird zur teuren Abhängigkeit, wenn der Workflow zu einer proprietären Fähigkeit werden sollte.
Die entscheidende Beschaffungsfrage lautet daher nicht, ob Presence intelligent klingt. Zu klären ist, wer das Ergebnis verantwortet, wer jede Aktion kontrolliert, wer die Sicherheit einer Änderung nachweist und wer den Workflow auffängt, wenn der Agent scheitert. Beantwortet der Vertrag diese Fragen und bestätigt der Pilotversuch die Wirtschaftlichkeit, kann Presence den schwierigsten Teil der Einführung von Unternehmensagenten verkürzen. Andernfalls ist ein engeres System, das sich messen und kontrollieren lässt, die bessere Wahl.
Ist OpenAI Presence als Self-Service-Produkt verfügbar?
Nein. Laut OpenAI steht Presence geeigneten Unternehmenskunden im Rahmen einer begrenzten allgemeinen Verfügbarkeit offen. Forward Deployed Engineers und ausgewählte globale Systemintegratoren leiten die Implementierungen; die Launch-Seite verweist Interessenten an ihr OpenAI-Account-Team.
Wie unterscheidet sich OpenAI Presence von ChatGPT Workspace Agents?
Workspace Agents sind gemeinsam nutzbare Agenten, die für wiederkehrende Aufgaben in ChatGPT erstellt werden und Apps, Tools, Slack, Zeitpläne sowie API-Trigger unterstützen. Presence ist eine betreute Produktivimplementierung für Echtzeit-Sprach- und Chatworkflows, die Unternehmenssysteme verwenden, kontrollierte Aktionen ausführen und an Menschen eskalieren.
Veröffentlicht OpenAI Preise für Presence?
Weder auf der Launch-Seite vom 22. Juli 2026 noch auf der aktuellen Frontier-Produktseite findet sich ein öffentlicher Listenpreis. Ein belastbares Angebot muss an einen definierten Workflow, dessen Volumen, Integrationsumfang, Supportmodell und messbare Erfolgskriterien gebunden sein.
Sollte ein Unternehmen Presence kaufen oder einen eigenen Agenten entwickeln?
Der Kauf ist sinnvoll, wenn ein richtlinienintensiver Sprach- oder Chatworkflow eine betreute Implementierung benötigt und das Unternehmen OpenAI als tief eingebundenen Betriebspartner akzeptiert. Eine Eigenentwicklung passt, wenn der Agent das Produkt differenziert, Architekturkontrolle strategisch ist, ungewöhnliche Bereitstellungsbedingungen gelten oder Modellportabilität und Stückkosten wichtiger sind als betreute Geschwindigkeit.
Bei der Entscheidung zwischen einem betreuten Agenten und einem System in eigener Hand hilft es, Workflow und Risikogrenze vor der Entwicklung abzubilden.
3. Sept. 2026
Diese Seite in Google bevorzugen
Markieren Sie omidsaffari.com als bevorzugte Quelle, und Google hebt die Seite für Sie in Top Stories, AI Overviews und AI Mode hervor.
