innFactory GmbH

Europa kann Robotik. Den ganzen Stack. NWS Digital GmbH zeigt, wie vollumfängliche Robotik aus Deutschland aussieht. Nicht als Prototyp mit Messedemo, sondern als produktives System für die Sicherheitsbranche. Dr. Fabian Mehring hat sich die NWS Guards vor Ort angeschaut. Der Guard K fährt autonom durchs Gelände, der Guard R sichert Gebäude von innen. Ab Missionsstart handeln die Roboter vollkommen autonom und kommen indoor wie outdoor auch ohne Internetverbindung zurecht. NWS entwickelt den gesamten Robotik Stack. Von der Hardware über die Firmware bis zur Cloud-Plattform. Die Roboter werden von NWS komplett aufgebaut, die Firmware selbst entwickelt, die Steuerungsplattform selbst gebaut. Dazu bietet NWS die gesamte Dienstleistung an, inklusive Auswertung der Alarme, wenn das gewünscht ist. Was das Ganze besonders macht: Der Aufbau auf dem Roboter kann wie ein Kuchen komplett individuell gestaltet werden. Egal welches Chassis, welche Drohne oder welcher Humanoide, die Payload kann überall drauf gebaut werden. NWS kann deshalb nahezu jeden Kundenwunsch erfüllen. Und die Cloud-Plattform kümmert sich um jeden Roboter, unabhängig vom Typ. Der Cloud Stack ist dabei vollkommen agnostisch. Er läuft in Azure, AWS, Google Cloud oder STACKIT und funktioniert bei besonderem Schutzniveau genauso in jeder On-Prem-Umgebung. Mit dem Robot Operation Center lassen sich alle Roboter zentral steuern, planen und auswerten. On Edge ist mit Edge AI einiges möglich. Jede Zeile Code ist auditierbar. Die zweite Generation des Softwarestacks haben wir bei der innFactory GmbH von Grund auf neu konzipiert und umgesetzt. Die Plattform passt zu jedem Roboter. Sowohl auf dem Gerät als auch in der Cloud steckt unglaublich viel Engineering. Ein kleines Wunderwerk der Technik, das wir softwareseitig begleiten dürfen. Bei diesem Projekt blüht mein Engineering-Herz förmlich auf. Danke an die Nürnberger Wach- und Schließgesellschaft mbH für die Einladung zum Austausch mit Fabian in Burgkirchen. Und natürlich auch an Fabian, dass du dir so viel Zeit für dieses wunderbare Projekt genommen hast. Wer mehr über den Stack erfahren möchte, darf sich gerne bei NWS Digital oder bei mir melden. Ich stelle gerne eine Verbindung her. Wo seht ihr Europas größte Stärken in der Robotik?

Dein Claude Max-Abo war nie günstig. Es war subventioniert. Anthropic beendet ab dem 15. Juni die Flatrate für programmatische Nutzung. Bisher liefen Agent SDK, claude p, GitHub Actions und Drittanbieter-Tools über dasselbe Kontingent wie der normale Chat. Wer intensiv automatisiert hat, hat Token im Wert von mehreren Hundert Dollar verbraucht und nur den Abo-Preis bezahlt. Diese Subvention fällt jetzt weg. Stattdessen führt #Anthropic ein separates monatliches Guthaben ein. Pro-Nutzer bekommen 20 USD. Max 5x bekommt 100 USD. Max 20x bekommt 200 USD. Das wird als Bonus verpackt. In Wahrheit wird dieses Guthaben zu vollen API-Preisen abgerechnet. Die Zahlen machen das Problem sichtbar. #Claude Opus 4.7 kostet 25 USD pro Million Output-Tokens. Sonnet 4.6 liegt bei 15 USD. Dazu kommen Cache-Write-Kosten von 3,75 bis 6,25 USD pro Million Tokens. In Agentic Workflows, wo ein Agent autonom arbeitet und dabei große Mengen Output-Tokens erzeugt, sind 200 USD Guthaben in wenigen Tagen aufgebraucht. Was danach passiert, entscheidest du selbst. Entweder aktivierst du Usage Credits und zahlst den Mehrverbrauch zu vollen API-Raten. Oder du wirst gesperrt, bis dein Guthaben im nächsten Abrechnungszyklus zurückgesetzt wird. Was ich in der Praxis sehe: Viele Teams haben ihre Claude-Nutzung nie in echten Dollar gemessen, weil die Flatrate das unsichtbar gemacht hat. Genau das war das Kalkül. Anthropic hat mit Subventionen skaliert, um den Markt für Agentic Engineering zu besetzen. Jetzt wird der reale Verbrauch monetarisiert. Die eigentliche Kompetenz liegt nicht darin, das günstigste Abo zu finden. Sie liegt darin, den tatsächlichen Token-Verbrauch pro Agent, pro Workflow und pro Modell zu kennen und aktiv zu steuern. Wer das nicht kann, wird von jeder Preisänderung kalt erwischt. Mit unserem #CompanyGPT ist das im übrigen möglich, wobei wir auch dort natürlich viel mit Anthropic zu normalen Preisen in den EU Regionen arbeiten. Anthropic ist damit nicht allein. GitHub stellt die #Copilot-Abrechnung zum 1. Juni auf exakt dasselbe Prinzip um. Dazu kommt in den nächsten Tagen ein eigener Post der euch zeigt wie sich unsere Kosten um den Faktor 8 verändern werden. Habt ihr eure Claude-Kosten unter dem neuen Modell schon durchgerechnet?

KI-Agenten-Frameworks wie Openclaw und Hermes sind kein n8n mit mehr Features. Das ist der häufigste Denkfehler, den man beobachten kann. Und er führt zu falschen Entscheidungen. Wenn SAP eigene Agent-Infrastruktur ankündigt und OpenClaw mit über 200.000 GitHub-Stars zum am schnellsten wachsenden Open-Source-Projekt wird, ist klar: Diese Kategorie kommt im Enterprise an. Aber was ist das eigentlich? n8n, Make oder Power Automate bauen Workflows. Du definierst jeden Schritt. Wenn Bedingung A, dann Aktion B. Die KI ist ein Baustein im Prozess. Alles ist explizit, nachvollziehbar und von der IT auditierbar. OpenClaw oder Hermes Agent arbeiten fundamental anders. Du gibst der KI ein Ziel und Systemzugang. Sie entscheidet selbst, welche Schritte sie ausführt. Sie liest Dateien, führt Kommandos aus, verbindet sich mit deinen Messaging-Kanälen und reagiert eigenständig auf Events. Kein Mensch klickt dazwischen auf "Weiter". Das ist keine Automatisierung. Das ist Delegation an eine Maschine. Der Unterschied klingt subtil, ist aber fundamental. Bei einem Workflow weißt du vorher, was passiert. Bei einem Agent weißt du es nicht. Du weißt nur, was er kann. Genau hier liegt das Enterprise-Problem. OpenClaw hatte wenige Wochen nach dem Launch schwere Sicherheitslücken, eine Angriffskampagne auf den Plugin-Marktplatz und Warnungen von Microsoft, CrowdStrike und Palo Alto. Nicht weil das Framework schlecht gebaut wäre. Sondern weil Systemzugang plus Entscheidungsautonomie plus Netzwerkzugriff eine Angriffsfläche erzeugen, die Workflow-Tools schlicht nicht haben. Hermes Agent von Nous Research zeigt, dass man das von Anfang an mitdenken kann. Sieben Sicherheitsschichten, nicht überschreibbare Blocklisten, echte Isolation zwischen Sessions. Aber auch Hermes braucht Betriebsverantwortung auf deiner Seite. Was mich in der Praxis beschäftigt: Viele Teams greifen zu Agent-Frameworks für Aufgaben, die ein klar definierter Workflow besser lösen würde. Ein Prozess mit bekannten Schritten braucht keinen autonomen Agenten. Er braucht eine saubere Automatisierung, die nachvollziehbar und auditierbar ist. Wer stattdessen einen Agenten deployt, tauscht Kontrolle gegen Bequemlichkeit. Die eigentliche Kompetenz ist nicht, ein Agent-Framework aufzusetzen. Sie ist die Fähigkeit zu unterscheiden: Wo brauche ich echte Autonomie, weil der Prozess nicht vorab definierbar ist? Und wo reicht ein Workflow, der genau das tut, was ich ihm sage? Wie autonom lasst ihr KI-Agenten in eurem Unternehmen laufen, und wo holt ihr den Menschen bewusst zurück in die Entscheidung? Und eine ehrliche Gegenfrage: Wenn der Prozess klar definiert ist, warum bildet ihr ihn nicht einfach als auditierbaren Workflow ab?

Prompt Engineering ist nicht die Kompetenz der Zukunft! Das klingt provokant, aber ich meine es ernst. Gerade wird Prompt Engineering behandelt, als wäre es eine eigenständige Disziplin. Es gibt Kurse, Zertifikate und Jobtitel dafür. Dabei ist ein Prompt nichts anderes als eine Frage. Und die Qualität einer Frage hängt nicht von der Formulierung ab, sondern davon, wie tief jemand ein Thema verstanden hat. Was ich in der Praxis sehe: Teams mit starkem Domänenwissen nutzen KI produktiver als Teams, die vor allem gelernt haben, Prompts zu optimieren. Sie erkennen Halluzinationen schneller. Sie iterieren gezielter. Sie wissen, wann die Ausgabe eines Modells brauchbar ist und wann nicht. Nicht weil sie bessere Prompts schreiben, sondern weil sie wissen, wonach sie eigentlich suchen. Das zeigt sich besonders bei Agenten. Ein Agent, der auf MCP-Server zugreift, Workflows auslöst und Entscheidungen vorbereitet, braucht jemanden, der den Prozess dahinter versteht. Kein Prompt-Template der Welt ersetzt das Verständnis dafür, welche Schritte in welcher Reihenfolge sinnvoll sind und wo ein Mensch eingreifen muss. Die Modelle werden besser. GPT-5, Claude, Gemini verstehen Kontext und Intention heute deutlich zuverlässiger als noch vor einem Jahr. Das bedeutet: Die Einstiegshürde bei der Formulierung sinkt. Was bleibt, ist die Fachkompetenz desjenigen, der das Modell einsetzt. Die wird sogar wichtiger, weil die Modelle komplexere Aufgaben übernehmen und die Bewertung der Ergebnisse anspruchsvoller wird. Prompt Engineering verschwindet nicht. Es wird absorbiert. So wie heute niemand mehr "Google-Suchexperte" auf seine Visitenkarte schreibt, wird Prompting eine Grundfähigkeit, die jeder mitbringt. Der Unterschied zwischen mittelmäßigen und exzellenten Ergebnissen liegt dann nicht im Prompt, sondern im Kopf der Person, die ihn schreibt. Welche Fähigkeiten wirklich zählen: Prozesse end-to-end verstehen, damit man einem Agenten beibringen kann, was er tun soll. Ergebnisse kritisch bewerten, statt die erste Ausgabe blind zu übernehmen. Daten und Systemlandschaften kennen, weil KI nur so gut ist wie der Kontext, den man ihr gibt. Und die Fähigkeit, ein Problem so zu zerlegen, dass ein Modell es überhaupt sinnvoll bearbeiten kann. Das sind keine neuen Skills. Es sind die gleichen Fähigkeiten, die schon immer den Unterschied gemacht haben. KI macht sie nur sichtbarer. Wer heute in Prompt-Kurse investiert statt in Fachkompetenz, optimiert das falsche Ende der Kette. Was ist eure Erfahrung? Wir setzen auf zentrale Skills, in unserem "Agentic Framework" und auf die Fachkompetenz unserer Mitarbeiter die wir mit CompanyGPT, Github Copilot und OpenCode im Alltag ausstatten.

Wie baut man eigentlich einen KI-Agenten? Diese Frage hört man gerade in jedem zweiten Gespräch wenn es Um Agentic AI geht. Und fast immer folgt direkt: Welches Tool sollen wir nehmen? Aber das ist die falsche Frage. Die richtige lautet: Welcher Ansatz passt zu unseren Ressourcen, unserem Reifegrad und unserer Geschwindigkeit? Es gibt nicht den einen Weg. Es gibt fünf grundlegend verschiedene Ansätze. Keiner ist besser oder schlechter. Sie liegen auf einer Achse zwischen maximalem Eigenaufwand mit voller Flexibilität und maximaler Geschwindigkeit mit weniger Gestaltungsspielraum. Ansatz 1: From Scratch mit Python und API. Du rufst direkt die API von OpenAI, Anthropic oder einem Open-Source-Modell auf und baust Logik, Memory und Tool-Anbindung selbst. Maximale Kontrolle, maximaler Aufwand. Sinnvoll, wenn du ein erfahrenes Produktteam hast und etwas wirklich Einzigartiges bauen willst. Ansatz 2: Agent Frameworks wie LangGraph, CrewAI, Google ADK, OpenAI Agents SDK, Claude Agent SDK oder AWS Strands. Ein 2026 explodierender Markt. LangGraph für komplexe stateful Workflows, CrewAI für rollenbasierte Agententeams, die SDKs und ADKs für modellnative Entwicklung. Sinnvoll, wenn du Entwickler hast, die agentic Patterns verstehen. Ansatz 3: KI-Plattformen wie CompanyGPT oder vergleichbare Lösungen. Du konfigurierst Agenten auf einer fertigen Plattform mit Governance, Datenschutz und Unternehmensanbindung. Der Agent greift über RAG auf interne Daten zu, interagiert über MCP-Server mit Systemen und wird zentral verwaltet. Sinnvoll, wenn du schnell produktiv werden willst, ohne ein AI-Engineering-Team aufzubauen. Ansatz 4: Low-Code mit n8n, Make oder Power Automate und Copilot Studio. Du baust Workflows visuell und steckst KI-Bausteine ein. Schnellster Time-to-Value, aber Grenzen bei komplexen Entscheidungslogiken. Sinnvoll für Fachabteilungen, die eigenständig automatisieren wollen. Ansatz 5: Embedded AI wie Copilot in Microsoft 365, Salesforce Agentforce oder SAP Joule. KI direkt in bestehender Software. Kein Build, keine Integration. Guter Einstieg, aber wenig Einfluss auf Verhalten und Datennutzung. Was ich in der Praxis sehe: Die meisten Unternehmen starten am besten mit Ansatz 3 oder 4. Der Aufwand ist überschaubar, die Ergebnisse kommen schnell und das Unternehmen lernt, was Agenten im eigenen Kontext leisten. Von dort wächst man bei Bedarf Richtung Ansatz 2, wenn klar ist, welche individuellen Workflows sich lohnen. Wer ohne erfahrenes Team bei Ansatz 1 startet, verbrennt Budget. Wer nur bei Ansatz 5 bleibt, bekommt keinen Wettbewerbsvorteil, weil die gleiche KI auch bei der Konkurrenz läuft. Die Landkarte ist groß. Aber sie wird übersichtlich, sobald man ehrlich auf die eigenen Ressourcen schaut, statt dem nächsten Framework-Hype zu folgen. Welchen Ansatz nutzt ihr aktuell?

Was früher eine Excel-Datei mit Makros war, ist heute eine vollständige Webapplikation. Gebaut in zwei Stunden. Von der Fachabteilung. Ohne eine einzige Zeile eigener Programmiererfahrung. Wir erleben das inzwischen wöchentlich in Beratungsprojekten. Und die meisten IT-Abteilungen sind darauf nicht vorbereitet. Das eigentliche Problem ist nicht die Qualität des Codes. Das eigentliche Problem ist, dass eine Webapplikation im Gegensatz zu einer Excel-Datei eine Angriffsfläche hat. Sie läuft in einem Netzwerk. Sie hat potenziell einen Endpunkt im Internet. Sie verarbeitet Daten, die sie per API, per Mail oder über ein Login-Portal nach außen geben kann. Und niemand in der IT weiß davon. Wir beobachten gerade die Entstehung von Schatten-IT 2.0. Nur dass diese Generation nicht aus Access-Datenbanken auf Abteilungslaufwerken besteht, sondern aus funktionsfähigen Webanwendungen auf privaten Cloud-Accounts. Drei Dinge, die ich aus den letzten Monaten gelernt habe: Erstens: Verbieten funktioniert nicht. Der Produktivitätsgewinn durch Vibe Coding ist real. Wer es blockiert, verliert Innovationskraft und treibt die Nutzung in noch unkontrolliertere Kanäle. Die einzig sinnvolle Antwort ist Kanalisierung. Zweitens: Die Standards existieren bereits. Vibe-Coding-Apps sind technisch gesehen Webapplikationen. Für Webapplikationen gelten seit Jahren dieselben Design Principles wie für Microservices: zentrale Authentifizierung, zentrales Logging, externalisierte Konfiguration, automatisierte Security Scans, kontrolliertes Deployment. IT-Abteilungen müssen keinen neuen Regelkatalog erfinden. Sie müssen den bestehenden auf eine neue Zielgruppe anwendbar machen. Drittens: Die Rolle der IT verändert sich fundamental. IT-Abteilungen werden in diesem Modell zum Plattformbetreiber. Sie stellen Infrastruktur, Pipelines und Guardrails bereit. Die Fachabteilung bleibt fachlicher Owner. Die IT wird nicht zum Entwickler, sondern zum Qualitätsgaranten. Das ist ein Paradigmenwechsel, den viele Organisationen noch nicht vollzogen haben. Der kritischste Punkt dabei: der Übergang vom Laptop ins verwaltete System. Solange eine App nur lokal läuft, ist sie ein Prototyp. Sobald sie Unternehmensdaten verarbeitet oder für andere zugänglich wird, muss sie in ein Repository, durch eine Pipeline und auf verwaltete Infrastruktur. Dieser Übergang entscheidet darüber, ob Vibe Coding ein Sicherheitsrisiko bleibt oder ein kontrollierter Innovationskanal wird. Ich habe in unserem innFactory AI Blog einen ausführlichen Leitfaden mit Reifegradmodell, Design Principles und einer Schritt-für-Schritt-Checkliste geschrieben. Wie geht ihr im Unternehmen mit Vibe Coding von Fachabteilungen um? #VibeCoding #ITGovernance #KI #Mittelstand #CIO

"Wir haben jetzt Claude in der EU, über AWS Bedrock." Diesen Satz höre ich in Beratungsgesprächen mehrmals pro Woche. Die unausgesprochene Erwartung dahinter: dass Mitarbeitende damit claude.ai nutzen können, datenschutzkonform und auf europäischem Boden. Das stimmt so nicht. Was Unternehmen über AWS Bedrock, Google Vertex AI oder Azure OpenAI bekommen, ist das Modell als API-Endpunkt. Was claude.ai, Claude Code oder ChatGPT ausmacht, ist die App darum herum: Memory, Projekt-Workspaces, Datei-Uploads, Voice-Modi, Coding-Agents, mobile Apps. Diese App wird von Anthropic und OpenAI selbst betrieben und bleibt primär auf US-Infrastruktur. Der Unterschied ist nicht akademisch. Er entscheidet darüber, ob eine KI-Strategie in der Praxis aufgeht oder nicht. Wer das App-Erlebnis in der EU möchte, mit eigener Datenhaltung und Anbindung an interne Systeme wie SharePoint oder Confluence, braucht eine eigene App-Schicht auf den Hyperscaler-APIs. Open-Source-Projekte wie LibreChat und OpenWebUI leisten dabei exzellente Grundarbeit. Für tiefere Enterprise-Anforderungen entscheidet am Ende die Tiefe des Stacks hinter der Lösung. Ich habe dazu einen ausführlichen Artikel geschrieben, der Modell und Produkt sauber trennt, die Hyperscaler-Angebote ehrlich einordnet und zeigt, welcher Weg für welches Szenario der richtige ist. 🔗 https://lnkd.in/dRcECCN9 #KI #ArtificialIntelligence #CloudComputing #DSGVO #EnterpriseAI #Claude #ChatGPT #AWSBedrock #AzureOpenAI #VertexAI

Wir haben ein großes Unternehmen beim Aufbau einer Microsoft Azure Landing Zone Architektur begleitet — von der Strategie bis zur produktiven Umsetzung. Dabei haben wir wertvolle Erfahrungen gesammelt, die wir nun in diesem Whitepaper zusammengefasst haben. Christian Diemers und ich verbinden darin Theorie und Praxis: die Empfehlungen des Azure Cloud Adoption Frameworks mit konkreten Erkenntnissen aus der Projektumsetzung. Von der Strategiephase über Identity & Governance bis hin zu Platform Engineering und Subscription Vending. Das Ergebnis ist ein praxisnaher Leitfaden für alle, die eine strukturierte und skalierbare Cloud-Plattform in Azure aufbauen möchten. Zum Download: https://lnkd.in/d8VfqYYD #Azure #LandingZones #CloudArchitecture #PlatformEngineering #innFactory

Sovereignty Washing ist vorbei: Schwarz Digits hat auf der Hannover Messe den European Sovereign Stack Standard (ES³) vorgestellt. Ein Reifegradmodell mit vier Leveln, neun Dimensionen und über 100 Kriterien, das digitale Souveränität erstmals objektiv bewertbar macht. Geprüft wird das Ganze von BDO als unabhängiger Instanz. Jeder IT-Service wird in neun Dimensionen bewertet, von Datenhaltung über Lieferkette bis hin zu einer komplett neuen Dimension speziell für Künstliche Intelligenz. Level 1 bedeutet starke Abhängigkeit von externen Anbietern. Level 4 bedeutet vollständige europäische Autonomie, offene Standards, kein US CLOUD Act Risiko. Entscheidend ist das Minimum-Prinzip: Die Gesamtbewertung entspricht immer dem schwächsten Level über alle Dimensionen. Souveränität kennt keine Ausnahmen. Besonders spannend wird es bei KI. Wo laufen Prompts und Antworten? Wer hat Zugriff? Werden Daten für Modelltraining genutzt? Genau diese Fragen macht ES³ beantwortbar und vergleichbar. Für jedes Unternehmen, das heute KI einsetzt oder einsetzen will, schafft dieses Framework die Grundlage für jede seriöse Entscheidung. Genau deshalb haben wir CompanyGPT so gebaut, dass es Level 2 bis 4 abdecken kann. Auf Level 4 läuft alles ausschließlich auf STACKIT mit Open-Source-Modellen. Den vollständigen Blogpost mit Vergleichstabelle aller drei Deployment-Varianten gibt es im innFactory AI Consulting GmbH Blog.