Tech Insights

Welche IoT-Plattformen unterstützen KI-Assistenten-Integrationen von Haus aus

Ein Einkaufsleitfaden für KI-Assistenten-Integrationen in IoT-Plattformen: der Test ohne Code, ohne Middleware, mit Berechtigungen, die drei ehrlichen Kategorien und wo AWS, Oracle, ThingsBoard, Telit, Losant und TagoIO wirklich stehen.

Fabio Rosa · · Aktualisiert am
Welche IoT-Plattformen unterstützen KI-Assistenten-Integrationen von Haus aus

Fragen Sie heute einen IoT-Anbieter nach KI, und Sie bekommen ein selbstbewusstes Ja. AWS verweist auf Amazon Q und Bedrock. Oracle verweist auf die eigene OCI IoT Platform. ThingsBoard, Telit und Losant haben jeweils eine KI-Seite zwei Klicks von der Startseite entfernt. Auf dem Papier ist die Frage geklärt.

Aber “unterstützt KI-Assistenten-Integrationen” reicht von einem Assistenten, der schon im Produkt wohnt und Ihre echten Geräte liest, bis zu einer Anleitung, die mit dem Bereitstellen von Cloud-Funktionen beginnt und drei Dienste später endet. Der Abstand zwischen diesen Antworten misst sich in Wochen Entwicklungsarbeit, und der Ausdruck, der ihn verdeckt, ist “von Haus aus”.

Der ehrliche Weg zur Antwort ist, den Ausdruck zuerst zu definieren und dann jede Plattform, unsere eingeschlossen, an derselben Definition zu messen.

Was “von Haus aus” bedeuten sollte

Der Ausdruck verdient seinen Namen, wenn drei Dinge zutreffen.

Ohne Code. Sie sollten keine Integrationsfunktion, keinen Webhook-Handler und keinen Parser schreiben müssen, bevor der Assistent Gerätedaten sieht. Konfigurieren ist in Ordnung. Programmieren nicht.

Ohne Middleware. Es gibt nichts Zusätzliches zu hosten oder zu betreuen. Der Assistent ist entweder in die Plattform eingebaut, oder er verbindet sich über eine Schnittstelle, die der Anbieter liefert, dokumentiert und aktuell hält.

Mit Berechtigungen. Der Assistent arbeitet innerhalb Ihres bestehenden Zugriffsmodells. Er beginnt mit dem geringsten Zugriff, der ihn nützlich macht, fragt, bevor er etwas ändert, und hinterlässt eine prüfbare Spur. Ein Assistent mit stillem Schreibzugriff auf Produktionsgeräte ist keine Funktion. Er ist ein Störungsbericht, der auf einen Zeitstempel wartet.

Der Von-Haus-aus-Test für einen KI-Assistenten: ohne Code, ohne Middleware und mit Berechtigungen, alle drei erforderlich, sonst handelt es sich um ein Projekt und nicht um eine Funktion

Halten Sie diesen Test gegen den Markt, und das Bild wird schnell scharf.

Drei Kategorien von “KI-Assistenten-Integration”

Fast jede Behauptung, die Sie lesen, fällt in einen von drei Töpfen. Sie sind nicht gleich leistungsfähig, aber jeder ist für manche Teams die richtige Antwort.

1. Eigener MCP-Server

Das Model Context Protocol (MCP) ist ein offener Standard, um KI-Assistenten mit externen Werkzeugen und Daten zu verbinden. Wenn eine Plattform ihren eigenen MCP-Server liefert, kann sich jeder MCP-fähige Assistent mit Ihrem Konto verbinden und über diesen Standard mit Ihren Daten arbeiten. Kein individuelles Integrationsprojekt nötig.

Die Einrichtung ist Konfiguration statt Programmierung, und der Zugriff folgt den Zugangsdaten, die Sie bereitstellen, diese Kategorie besteht den Test also. Oracle hat einen MCP-Server für die OCI IoT Platform veröffentlicht, und ThingsBoard pflegt einen, der Geräte, Telemetrie und Verwaltung freigibt. TagoIO steht ebenfalls hier. Wenn eine dieser Plattformen auf Ihrer Auswahlliste steht, ist der MCP-Server die zu prüfende Funktion, nicht die KI-Marketingseite.

Der Tausch ist, dass Sie sich auf den offenen Standard einlassen, den die Plattform unterstützt, und Sie sollten prüfen, was der Server in Ihrem Namen tatsächlich lesen und tun darf.

2. Offene REST-API, die Sie selbst anschließen

Viele Plattformen stellen eine dokumentierte REST-API bereit und darüber nichts KI-Spezifisches. AWS hat den tiefsten KI-Werkzeugkasten der Branche: Bedrock-Agenten erreichen IoT-Daten, Amazon Q kann über Ihre Cloud-Ressourcen schlussfolgern, und AWS IoT SiteWise enthält einen Assistenten für Industriedaten. Was AWS nicht liefert, ist ein vorverbundener Weg von einem allgemeinen Assistenten zu Ihrer Geräteflotte. Diesen Weg setzen Sie selbst zusammen: IAM-Rollen, Agentendefinitionen, Datenquellen und den Kitt dazwischen. Eine selbst betriebene ThingsBoard-Installation ohne dessen MCP-Server landet an derselben Stelle.

Das funktioniert, und für ein Unternehmen mit Cloud-Fachleuten im Haus können die Ergebnisse hervorragend sein. Sie bestimmen Umfang, Authentifizierung und Verhalten. Den Ohne-Code-Test besteht es dennoch nicht, gerade weil es ein Projekt ist. Jemand muss die Hülle schreiben, sie pflegen, wenn sich die API ändert, und die Sicherheit der Zugangsdaten tragen, die sie hält. Für ein Team mit den richtigen Leuten ist dieser Besitz ein Vorteil, keine Last.

3. KI, die kein Gesprächsassistent ist

Die dritte Kategorie erhält das meiste Marketing und die geringste Prüfung, und sie teilt sich in zwei.

Ein eingebauter Chatbot lebt in der Oberfläche der Plattform. Er beantwortet Fragen, fasst ein Dashboard zusammen, entwirft manchmal eine Abfrage, alles innerhalb dieses einen Bildschirms. Für nicht technische Nutzende kann das echt nützlich sein. Die Grenze ist strukturell: Ihre externen Werkzeuge erreichen diesen Assistenten nicht.

Die andere Form ist KI, die woanders investiert wurde. Telits Reihe deviceWISE AI konzentriert sich auf Intelligenz an der Kante und Maschinensehen, was ein echtes Problem löst, aber kein Gesprächsassistent über Ihr Konto ist. Losants Weg führt über die Workflow-Engine, in der Sie Aufrufe an KI-Dienste in selbst entworfene Abläufe einhängen. Das ist flexibel, und man darf es KI-Unterstützung nennen. Es ist auch eine Integration, die Sie bauen.

Nichts davon ist ein Vorwurf an diese Plattformen. Es ist eine Erinnerung, dass “KI” auf einer Funktionsliste einen Gesprächsassistenten, Inferenz an der Kante oder Workflow-Verrohrung bedeuten kann, und das Etikett allein verrät nicht, was Sie kaufen.

Wie die Ansätze sich vergleichen

Eigener MCP-Server Offene REST-API Eingebauter Chatbot oder Edge-KI
Zugriff für externe Assistenten Ja, über einen offenen Standard Ja, nachdem Sie es gebaut haben Nein
Bauaufwand Keiner für die Verbindung Eigener Kitt oder eigene Hülle Keiner
Wer beschränkt die Zugangsdaten Die Plattform, durch Bauweise Sie Nicht anwendbar
Am besten für Teams, die jetzt externen KI-Zugriff wollen Entwicklungsteams, die volle Kontrolle wollen Nutzende in der Oberfläche, oder Edge-Inferenz
Hauptrisiko Prüfen, was der Server lesen und tun darf Pflege und Besitz der Zugangsdaten liegen bei Ihnen Kommt nicht aus dem Dashboard heraus
Beispiel TagoIO, Oracle OCI, ThingsBoard AWS IoT Core, selbst betriebene Stacks Telit deviceWISE AI, Losant-Workflows

Keine davon ist eine Falle. Ein eingebauter Chatbot ist gut, wenn Ihre Nutzenden im Dashboard leben. Eine API, die Sie selbst anschließen, ist gut, wenn Sie Entwicklung im Haus haben und Kontrolle wollen. Ein eigener MCP-Server ist der kürzeste Weg zu externem, standardbasiertem Zugriff. Der Fehler ist, das eine zu kaufen und zu glauben, man habe das andere gekauft.

TagoIO Weg eins: TagoAI, schon im Admin

TagoIO liefert zwei Wege, gebaut für zwei verschiedene Situationen.

Der erste ist TagoAI, ein Assistent im TagoIO Admin hinter dem Sternsymbol in der Seitenleiste. Er kennt den Kontext: Öffnen Sie ihn von einer Analysis- oder Dashboard-Seite, und er weiß bereits, worauf er schaut. Er beantwortet Architekturfragen verankert in der offiziellen Dokumentation, sieht Devices, Dashboards, Actions und Analysis-Skripte an und bearbeitet sie, erzeugt Analysis-Code passend zu Ihren echten Geräten und Datenformaten, debuggt Skripte, die zicken, und führt Datenanalysen über Ihre Flotte aus. Es gibt nichts zu installieren und nichts zu hosten, und genau das soll eingebaut bedeuten.

Das Berechtigungsmodell ist der Teil, den man zweimal lesen sollte. TagoAI startet jede Sitzung nur lesend. Sie heben die Berechtigung pro Sitzung an, wenn Änderungen gewünscht sind, er ändert nie etwas stillschweigend, er kann die Berechtigungen Ihres eigenen Kontos nicht überschreiten, und jede Handlung steht im Audit Log. Das ist der dritte Test, bestanden durch Bauweise statt durch ein Regelwerk.

Der Datenschutz wird gleich behandelt. Die Standardanbieter für KI arbeiten unter Vereinbarungen, die Training mit Ihren Daten verhindern. Will Ihre Compliance mehr Kontrolle, können Sie einen eigenen Anbieter mitbringen, unterstützt werden OpenAI, Anthropic, AWS Bedrock, Google Gemini und OpenRouter, Ihre Schlüssel liegen verschlüsselt in TagoIO Secrets. Ein eigener Anbieter hebt außerdem das monatliche Promptlimit auf. Die Funktion lässt sich pro Profil abschalten und ist in der EU-Region standardmäßig aus. Das vollständige Bild zu Verankerung, Berechtigungen und Anbieterwahl geht tiefer, als dieser Überblick kann.

Um es an einem echten Konto statt auf einer Folie zu sehen: Das aufgezeichnete Webinar AI Meets IoT: A Practical Experience with TagoAI zeigt Live-Sitzungen, einschließlich der Berechtigungsabfragen.

TagoIO Weg zwei: ein MCP-Server für den Assistenten, den Sie schon nutzen

Viele Teams leben bereits in Claude oder einem anderen MCP-fähigen Assistenten und haben kein Interesse am Fensterwechsel. Für sie veröffentlicht TagoIO einen offiziellen MCP-Server, quelloffen auf GitHub, der einen externen Assistenten mit Ihrem Konto verbindet: Geräte, Daten, Analysis-Skripte und Dashboards, alles über ein Token, das Sie beschränken und steuern. Er arbeitet mit Claude, ChatGPT, Cursor und Windsurf, und Version 3.0.0 brachte Unterstützung für entfernten HTTP-Betrieb, der Server muss also nicht auf Ihrem eigenen Rechner laufen.

Die zwei Wege ergänzen sich, sie konkurrieren nicht. TagoAI ist der Assistent im Admin, der weiß, auf welcher Seite Sie sind. Der MCP-Server bringt Ihr TagoIO-Konto zu dem Assistenten, dem Ihr Team schon vertraut. Beide bestehen alle drei Tests, und die meisten Konten nutzen am Ende beide.

Eine Checkliste für jedes Anbietergespräch

Anbietermarketing wird diese Unterschiede nicht für Sie zeichnen, bringen Sie also eigene Fragen mit.

  • Kann ein externer Assistent meine Daten erreichen? Das ist der erste Schnitt. Lautet die Antwort “nur in unserem Dashboard”, sind Sie in Kategorie drei. Das kann passen, aber jetzt wissen Sie es.
  • Über welchen Standard? Ein offener Standard wie MCP heißt, dass Ihre vorhandenen Assistenten sich ohne Sonderarbeit verbinden. Eine proprietäre Integration bindet Sie an eine Anbieterbeziehung.
  • Startet der Assistent nur lesend, und was hebt seine Berechtigung an? Lesezugriff auf Telemetrie ist etwas ganz anderes, als Skripte anlegen, Dashboards ändern oder Aktionen auslösen zu können. Holen Sie die genaue Liste.
  • Wo werden seine Handlungen protokolliert? Eine Prüfspur ist der Unterschied zwischen einem Werkzeug, das Sie ausrollen können, und einem, das Ihre Sicherheit blockiert.
  • Wessen KI-Modell sieht Ihre Daten, unter welcher Vereinbarung, und können Sie einen eigenen Anbieter mitbringen? Fragen Sie auch, ob sich das Ganze für ein Profil abschalten lässt, das es nicht haben darf.
  • Läuft er entfernt oder nur auf meinem Rechner? Ein Server, der einen lokalen Prozess braucht, ist für ein Team schwerer zu betreiben.

Ein Anbieter mit echter Unterstützung von Haus aus beantwortet das in der Dokumentation. Ein Anbieter mit einer Marketingseite beantwortet es in einem Dienstleistungsangebot.

Ein kurzer Entscheidungsleitfaden nach Käufertyp

Nicht technisches Team. Arbeiten Ihre Leute in der Plattform und verlassen sie selten, deckt ein eingebauter Assistent den Bedarf womöglich ohne Einrichtung. Wollen Sie zusätzlich Antworten aus dem Assistenten, den Sie sonst nutzen, suchen Sie einen eigenen MCP-Server.

Entwicklungsteam. Wenn Sie Entwicklung im Haus haben und genau steuern wollen, was ein Assistent darf, passen beide Wege, der eigene MCP-Server und die selbst angeschlossene API. Nehmen Sie den MCP-Server, um den Bau zu sparen; nehmen Sie die API, wenn Sie Kontrolle brauchen, die der Standardserver nicht gibt, oder wenn Ihre Plattform gar keinen MCP-Server anbietet.

Integrator oder Lösungsbauer. Wenn Sie IoT-Lösungen an Kunden ausliefern, können Sie mit einem eigenen MCP-Server jedem Kunden KI-Zugriff geben, ohne pro Projekt eine neue Integration zu schreiben. Eine offene API bleibt als Grundlage wichtig, aber die standardisierte Verbindung ist das, was über Konten hinweg skaliert.

Wo das den Überblick hinterlässt

Oracle und ThingsBoard unterstützen externe Assistenten von Haus aus über MCP-Server. AWS unterstützt fast alles, sofern Sie es bauen. Telit und Losant haben ihre KI-Investition in Edge-Inferenz und Workflow-Werkzeuge gesteckt statt in Gesprächsassistenten. TagoIO liefert beide Hälften: TagoAI eingebaut im Admin und einen quelloffenen MCP-Server für externe Assistenten, mit derselben Berechtigungsdisziplin auf beiden Seiten.

Wenn der allgemeine Ausdruck “KI-Assistenten-Integration” Sie hierher gebracht hat, ist der Test zum Mitnehmen: ohne Code, ohne Middleware, mit Berechtigungen. Wenden Sie ihn auch auf uns an: starten Sie kostenlos und drücken Sie das Sternsymbol, oder buchen Sie eine Demo, wenn Sie es lieber vorgeführt sehen.

Ressourcen