Lifecycle stage — Build
KI, die innerhalb eines physischen Systems läuft, ist ein anderes Engineering-Problem als KI, die in einer Cloud läuft. Ein Modell, das auf einer SPS einer Produktionslinie, einer ECU in einem Fahrzeug oder einem Compute-Knoten an einer Umspannstation betrieben wird, muss Echtzeit-SLAs halten, Netzwerkpartitionen überleben, Sicherheitshüllen respektieren, die Ihre Zertifizierungsingenieure prüfen werden, und auf Hardware laufen, deren Kosten das Operations-Accounting freigeben kann. Generische Cloud-KI-Beratungen können diese Arbeit nicht leisten — die Referenzarchitekturen greifen nicht und die Teams sind nie einem Safety-Engineer begegnet. Das sind die PILOT- und LAUNCH-Phasen der DEPLOY Method, adaptiert für physische Systeme: ein 16-wöchiges eingebettetes Engagement, das einen Edge-KI-Piloten durch Safety-Discovery, Modelldesign für beschränkte Hardware, Integration mit dem Industrie- oder Fahrzeugstack und die operative Übergabe führt. Ich bin französischer Regierungs-KI-Botschafter für Finance & Business Digital Transformation — eine Designation, die für souveräne und verteidigungsnahe Arbeit zählt — und ich habe acht KI-Ventures ausgeliefert, darunter Arbeit an autonomen Systemen. Das Ergebnis ist eine Bereitstellung, die Ihr Operations-Team betreibt — keine Demo, die Ihr Data-Team aufgibt.
Ihre Cloud-First-Datenplattform wurde nie dafür entworfen, ein Modell auf eine SPS, eine Fahrzeug-ECU oder einen Compute-Knoten an einer Umspannstation auszubringen — und sie nachzurüsten ist für sich schon ein Projekt über drei Quartale. Der MLOps-Stack, den Ihr Team gebaut hat, setzt elastische Cloud-Inferenz, Netzwerkkonnektivität und überprovisionierbare Hardware voraus. Keine dieser Annahmen hält am Edge. Das Modell, das Ihr Data-Team trainiert hat, läuft auf Hardware, die Ihr Operations-Team kontrolliert, mit Beschränkungen, die Ihre MLOps-Pipeline nicht ausdrücken kann. Das Retrofit wird zum eigenen Programm und frisst die Zeitlinie, die das ursprüngliche KI-Projekt liefern sollte.
Safety- und Zertifizierungsingenieure haben ein Vetorecht, und Sie haben keinen Prozess, der die von ihnen benötigte Evidenz erzeugt. Das Modell funktioniert in der Simulation. Ihr Safety-Engineer verlangt die Gefährdungsanalyse, die Failure-Mode-Abdeckung, Tests zu Envelope-Verletzungen und die Evidenzkette, die einer Zertifizierungsprüfung standhält — und Ihr Data-Team hat keines dieser Artefakte je produziert. Das Projekt stockt in einem Review, von dem Ihr Data-Team bis Woche zehn nichts wusste. Niemand hat unrecht; die Übergabe zwischen ML-Engineering und Safety-Engineering wurde bei Ihnen nie entworfen, weil Sie nie KI in ein reguliertes physisches System ausgeliefert haben.
Ihr KI-Team und Ihr Operations-Team sprechen verschiedene Sprachen, und ihre Ticketsysteme reden nicht miteinander. Data-Scientists sprechen in F1-Scores, Validierungssets und Model Cards. Operations-Engineers sprechen in OEE, MTBF, SPS-Scan-Zyklen und Fahrzeugbus-Timing. Die beiden Gruppen treffen sich in einem Quartals-Steering-Committee und trennen sich, ohne sich auf Konkretes geeinigt zu haben. Ohne gemeinsame Sprache und einen gemeinsamen Operating Rhythm wird das Modell, das Ihr Team geliefert hat, nie vom Operations-Team akzeptiert, das es betreiben soll. Das Projekt scheitert nicht technisch; es scheitert sozial.
Das Modell funktioniert auf dem Prüfstand und kippt, sobald es einen echten Sensor mit fehlerhafter Kalibrierungsdrift trifft. Die Trainingsdaten waren sauber. Die Validierungsdaten waren sauber. Der Produktionssensor hat einen thermischen Bias, den niemand modelliert hat, eine Firmware-Version, von der Ihr Team nichts wusste, und einen sporadischen elektrischen Fehler, den das Operations-Team seit sechs Jahren toleriert. Die Genauigkeit des Modells bricht am dritten Tag des Piloten ein, und niemand kann sagen, ob das Modell, der Sensor oder die Integration kaputt ist. In dieser Mehrdeutigkeit sterben Edge-KI-Projekte.
Das Engagement läuft in vier vierwöchigen Phasen. Ich arbeite in der ersten und letzten Phase vor Ort und dazwischen remote eingebettet. Ihre Engineering-, Safety- und Operations-Teams haben alle zugewiesene Zeit — diese Lieferung kann ein Data-Team nicht allein tragen. Das Ergebnis ist eine Bereitstellung, die auf der Produktionshardware läuft, unter dem Safety-Regime, integriert in den operativen Stack.
Strukturierte Sitzungen mit dem Safety-Engineering-Team, der Zertifizierungsleitung, den Operations-Engineers, die das System betreiben werden, und dem ML-Team, das den Piloten gebaut hat. Wir dokumentieren die Sicherheitshülle, die relevanten Failure Modes, die erforderlichen Zertifizierungsartefakte, die Hardware-Beschränkungen (Compute, Memory, Thermik, Leistung), die Netztopologie und das Verhalten bei Partitionen sowie die operativen SLAs, die das Modell erfüllen muss. Am Ende von Woche vier liegt ein schriftliches Constraint-Dokument vor, das der Safety-Engineer unterzeichnen und gegen das das ML-Team bauen kann. Diese Phase ist diejenige, die die meisten Projekte überspringen; genau deshalb scheitern sie.
Die Modellarchitektur und das Trainingsrezept werden für die Hardware und die Sicherheitshülle neu entworfen. Quantisierungsstrategie, Latenzbudget, Speicher-Footprint, deterministisches Verhalten, wo Safety es verlangt, graduelle Degradation bei Sensorfehlern. Wir fahren Ablationen auf echter Hardware, nicht in der Simulation. Wir bauen zudem die Evidenzkette — Gefährdungsanalyse, Failure-Mode-Abdeckung, Envelope-Verletzungstests —, die das Zertifizierungsreview verlangen wird. Das in dieser Phase produzierte Modell ist jenes, das ausgeliefert wird; wir re-architektieren nicht, nachdem die Zertifizierungsevidenz aufgebaut ist.
Das Modell wird in den Industrie- oder Fahrzeugstack auf echter Hardware integriert — SPS-Programmierumgebung, OT-Netzwerk, Fahrzeugbus, SCADA oder Umspannwerks-Automatisierung. Das Ticketsystem des Operations-Teams erhält die Alarme, die das Modell erzeugen wird. Der Firmware-Update-Pfad, der Modell-Rollback-Mechanismus und die Over-the-Air- (oder Over-the-Wire-)Deployment-Pipeline werden gebaut und getestet. Am Ende von Woche zwölf läuft das Modell auf Produktionshardware in einer kontrollierten Pilotzone — einer Produktionslinie, einem Fahrzeug, einer Umspannstation — unter dem Safety-Regime und vom Operations-Team überwacht.
Das Operations-Team besitzt die Bereitstellung. Wir bauen die Runbooks, die sie nutzen werden, die Alarmschwellen, die zu ihrem bestehenden operativen Rhythmus passen, die Modell-Performance-Dashboards, die sie ohne ML-Ausbildung lesen können, und die Rollback-Playbooks für den Fall, dass ein Firmware-Update um 2 Uhr nachts schiefgeht. Wir expandieren von der Pilotzone auf den in Woche eins vereinbarten Produktions-Footprint — Linie für Linie, Fahrzeug für Fahrzeug, Standort für Standort — mit der Freigabe des Safety-Engineers für jede Ausweitung. Wenn ich gehe, betreibt das Operations-Team das System. Das ML-Team wird zu Modell-Updates konsultiert, nicht im Tagesbetrieb.
Hersteller, Automotive-OEMs, Energieversorger und Public-Sector-Stellen mit einem Pilot-KI-Projekt am Edge — in einer Fabrik, einem Fahrzeug, einer Umspannstation oder an einem souveränen Infrastrukturstandort. Organisationen, bei denen die Engineering-Leitung bereits weiß, dass die Lücke zwischen Cloud-KI und Physical AI real ist, ein Zertifizierungs- und Safety-Regime besteht, das das Projekt durchlaufen muss, und die eine externe Stimme brauchen, die schon zuvor KI in physische Systeme ausgeliefert hat. Souveräne Infrastrukturprogramme, die für verteidigungsnahe oder strategische-Industrie-Arbeit einen AI-Ambassador-akkreditierten Partner benötigen. Das ist nicht für reine Softwarefirmen — diese brauchen den Agentic-System-Engineering-Service. Es ist auch nicht für Organisationen ohne bereits laufenden Piloten; das Engagement setzt ein bestehendes Modell und ein Operations-Team zur Übergabe voraus.
Neben ihnen, mit klaren Scope-Grenzen. Ihr Automatisierungspartner besitzt die SPS-Programmierumgebung, das OT-Netzwerk und die operative Integrationsschicht — das ist seine Kernkompetenz, und ich werde nicht versuchen, darin hineinzuwachsen. Ich besitze die Modellarchitektur, die Edge-Inference-Bereitstellung, die Zertifizierungs-Evidenzkette und den Safety-Prozess. Wir treffen uns wöchentlich während des Engagements, damit die Arbeitsergebnisse zueinander passen. Ich habe das neben großen Industrieautomatisierern gemacht; die Grenze funktioniert sauber, wenn beide Seiten sie respektieren.
Ja — und oft muss es das. Ein Modell auf einer Fahrzeug-ECU, einer abgelegenen Umspannstation oder einer Fabrikzone mit sporadischer Konnektivität muss während Netzpartitionen arbeiten und seinen Zustand synchronisieren, wenn die Verbindung zurückkommt. Die Architektur behandelt das explizit: On-Device-Inferenz, lokales State-Management, Konfliktlösung bei eintreffender Telemetrie auf der zentralen Plattform und graduelle Degradation, wenn ein abhängiger Service unerreichbar ist. Das Design speist sich aus dem, was ich bei Auralink gebaut habe, wo Agenten weiterarbeiten müssen, wenn eine Abhängigkeit ausfällt.
Je nach Regime. Das Engagement produziert die Zertifizierungs-Evidenzkette — Gefährdungsanalyse, Failure-Mode-Abdeckung, Envelope-Verletzungstests — passend zum Standard, mit dem Ihr Safety-Engineer arbeitet. Ich bin keine Zertifizierungsstelle und ersetze Ihren Safety-Engineer nicht; ich baue die Evidenz in der Struktur, die er braucht, damit das Review nicht stockt. Speziell für EU-AI-Act-High-Risk-Klassifizierungen wird die Evidenzkette explizit gegen die Annex-III-Anforderungen entworfen, weil dort industrielle und autonome-System-Bereitstellungen in der Regel landen.
Das, was Ihr Operations-Team genehmigen wird. In Woche eins identifizieren wir den realistischen Hardware-Envelope — was Procurement kauft, was Operations installiert, was Wartung servicen kann. Ich habe mit Jetson, Intel, AMD und Custom-Silicon gearbeitet. Das Modelldesign richtet sich nach den Hardware-Beschränkungen, nicht umgekehrt; ich komme nicht mit einer Lieblingsplattform, weil die richtige Hardware die ist, die Ihr Operations-Team in den nächsten zehn Jahren tatsächlich betreiben wird.
Nicht substanziell. Die vier Phasen repräsentieren jeweils eine andere Disziplin — Safety, ML-Engineering, Industrieintegration, Operations — und jede braucht ihre Zeit. Die Safety-Phase zu verkürzen produziert eine Bereitstellung, die die Zertifizierung nicht besteht. Die Integrationsphase zu verkürzen produziert eine Bereitstellung, die das Operations-Team ablehnt. Die einzige Stelle, an der ich manchmal Zeit sparen kann, ist, wenn ein bestehender Industrieautomatisierungs-Partner bereits erhebliche Integrationsarbeit geleistet hat; das Engagement fokussiert dann auf Modell- und Safety-Schicht, und die Integrationsphase komprimiert sich auf zwei Wochen. Ich sage Ihnen in Woche eins, ob das zutrifft.
Entdecken Sie weitere Services, die dieses Angebot ergänzen
30 Minuten. Ich diagnostiziere Ihre Situation und sage Ihnen ehrlich, ob dieser Service passt — und wenn nicht, welcher.