Robotik & KI

KI-Roboter im Unternehmen integrieren: Die Praxischeckliste zum Download

Vom klaren Einsatzbereich bis zur schriftlichen Freigabe: So planen Schweizer Unternehmen die Integration von KI-Robotern. Mit druckbarer 7-seitiger Praxischeckliste, 42 Checkpunkten und Abnahmeblatt.

Titelbild: KI-Roboter im Unternehmen integrieren: Die Praxischeckliste zum Download
RoboTrends Schweiz

Ein KI-Roboter wird nicht durch einen gelungenen Demonstrationsfilm zum verlässlichen Betriebsmittel. Entscheidend ist, ob er eine klar beschriebene Aufgabe unter realen Bedingungen sicher, wirtschaftlich und nachvollziehbar erfüllt. Unsere Praxischeckliste hilft Schweizer Unternehmen, diese Entscheidung vorzubereiten – vom ersten Prozessblatt bis zur schriftlichen Betriebsfreigabe.

Praxischeckliste «KI-Roboter sicher integrieren» als PDF öffnen

Die geprüfte, druckbare Arbeitsvorlage umfasst 7 Seiten mit 42 Checkpunkten, konkreten Nachweis-Hinweisen, Rollen sowie Feldern für Datum und Visum. Ein separates Abnahme- und Entscheidungsblatt hält Freigabeumfang und offene Punkte fest. Das PDF ist zum Ausdrucken und handschriftlichen Ausfüllen gedacht, kein interaktives PDF-Formular. Über den Link lässt es sich öffnen und bei Bedarf speichern.

Stand: 7. November 2026. Titelbild: KI-generierte redaktionelle Illustration, keine Aufnahme eines tatsächlichen Betriebs. Die Checkliste ersetzt weder eine anwendungsspezifische Risikobeurteilung noch rechtliche Prüfung oder technische Validierung.

Ein fiktiver Schweizer Zulieferer als Praxisfaden

Stellen wir uns einen Zulieferer im Schweizer Mittelland vor: Wiederkehrende Bauteile sollen nach einem bestehenden Prüfschritt erkannt und für den nächsten Prozess bereitgestellt werden. Heute übernehmen Mitarbeitende diese repetitive Arbeit. Das Unternehmen möchte Entlastung schaffen, ohne die Qualität oder Lieferfähigkeit zu verschlechtern. Dieses Beispiel ist hypothetisch und ausdrücklich kein realer Kundenfall. Es enthält weder belegte Leistungswerte noch eine fertige technische Lösung.

Der erste Projektauftrag lautet deshalb nicht «Wir brauchen einen humanoiden Roboter». Er lautet: «Wir wollen diesen abgegrenzten Prozess verbessern und seine Eignung für Automatisierung prüfen.» Damit werden Varianten, Störungen, Verantwortlichkeiten und Alternativen sichtbar, bevor jemand Hardware bestellt. Die folgenden Schritte erklären, wie das Team die Arbeitsvorlage dafür nutzt.

1. Den Einsatzbereich enger beschreiben als das Verkaufsversprechen

Ein brauchbares Prozessblatt beschreibt Aufgabe, Bauteilfamilien, Arbeitsplatz, beteiligte Personen und relevante Umgebungsbedingungen. Ebenso wichtig sind Ausschlüsse: unbekannte Teile, andere Räume oder zusätzliche Aufgaben gehören nicht automatisch zum freigegebenen Einsatzbereich. «Kann flexibel arbeiten» ist kein prüfbares Lastenheft. Das Team muss erkennen können, wann die Maschine innerhalb ihrer Grenzen arbeitet und wann menschliche Übernahme nötig ist.

Beim fiktiven Zulieferer bleibt der nachgelagerte Qualitätsentscheid zunächst beim bestehenden Verfahren. Der Roboter darf nicht nebenbei Ausschussfreigaben erteilen oder Produktionsaufträge verändern. Ein neues Teil braucht eine neue Bewertung. Diese Begrenzung verhindert, dass aus einer überschaubaren Bereitstellungsaufgabe unbemerkt ein autonomer Produktionsentscheider wird.

Vor dem Pilot gehören Erfolg, Abbruch und Eskalation aufs Papier. Welche Qualitätsabweichungen sind akzeptabel? Welche Eingriffe werden erfasst? Wer kann den Versuch stoppen? Dabei geht es um projektspezifische Kriterien, nicht um pauschale technische Grenzwerte. Meldende dürfen durch ein berechtigtes Stoppsignal keine Nachteile erfahren.

2. Den einfachsten geeigneten Robotertyp wählen

Ein stationärer Roboterarm, ein Cobot, ein autonomer mobiler Roboter (AMR) oder eine konventionelle Automatisierung können sinnvoller sein als ein Humanoider. Vielleicht genügt sogar eine bessere Vorrichtung mit Kameraprüfung. Verglichen werden Eignung, Risiken, Integrationsaufwand und Gesamtkosten – nicht die Ähnlichkeit mit einem Menschen. KI ist dort wertvoll, wo sie eine konkrete Schwierigkeit löst, etwa wechselnde visuelle Merkmale.

Unser Zulieferer prüft deshalb zuerst eine örtlich begrenzte Lösung. Für einen reinen Transportbedarf wäre dagegen ein geeignetes mobiles System zu untersuchen. Die Auswahl folgt der Aufgabe; die Schutzanforderungen folgen der gesamten Anwendung. Auch ein einfacher Roboter kann bei ungeeignetem Werkzeug oder falscher Integration erhebliche Risiken erzeugen.

Aktuelle Forschung liefert Ideen, aber keine betriebliche Freigabe. Unsere Beiträge zu Meta Max und Max 2 sowie zu Metas Weltmodellen, V-JEPA und RoboJEPA ordnen solche Entwicklungen ein. Für die Beschaffung zählen nachgewiesene Fähigkeiten in der eigenen Aufgabe, verfügbare Betreuung und beherrschbare Grenzen.

3. Verantwortung und Gesamtkosten vor der Bestellung klären

Projektleitung, Fachbereich, Betreiber, Integrator, IT/OT, Datenschutz und Arbeitssicherheit brauchen benannte Verantwortliche samt Stellvertretung. Der Anbieter liefert nicht automatisch alle Nachweise für den späteren Einsatzort. Bei Umbauten muss fachlich geklärt werden, welche Herstellerpflichten entstehen können. Die Zuständigkeit für eine Unterschrift ist dabei nicht dasselbe wie die Kompetenz, Sicherheitsfunktionen zu validieren.

Für den fiktiven Zulieferer führt die Projektleitung die offene Punkte-Liste. Produktion beschreibt den Prozess, IT/OT die Anbindung und die zuständige Safety-Fachperson bewertet die Anwendung. Jede Abweichung erhält eine verantwortliche Person und einen Termin. So verschwinden kritische Fragen nicht zwischen Einkauf, Lieferant und Betriebsunterhalt.

Das Budget umfasst neben dem Roboter Integration, Greifer, Schutztechnik, Netzwerk, Schulung, Wartung, Energie und Ausfallzeiten. Hinzu kommen Assistenzaufwand, Ersatzteile und ein manueller Rückfallprozess. Verglichen wird die Gesamtlösung mit dem heutigen Ablauf. Eine schnelle Bewegung ist kein wirtschaftlicher Vorteil, wenn häufige Unterbrechungen Personal binden oder die Nacharbeit steigt.

Schon im Angebot sollte erkennbar sein, welche Leistungen der Lieferant übernimmt und welche Nachweise der Betreiber bereitstellen muss. Unser Zulieferer verlangt deshalb eine nachvollziehbare Abgrenzung von Inbetriebnahme, Schulung, Schnittstellenarbeit und späterem Support. Offene Annahmen werden nicht als zugesicherte Fähigkeiten verbucht. Auch laufende Softwaregebühren und die Verfügbarkeit einer freigegebenen Modellversion gehören in die Entscheidung: Eine günstige Hardware allein schützt nicht vor teuren Abhängigkeiten.

4. Safety betrifft die Anwendung, nicht das Cobot-Etikett

Beurteilt werden Roboter, Werkzeug, Werkstück, Last, Umgebung, Menschen und Betriebsarten zusammen. «Kollaborativ» bedeutet nicht, dass jeder gemeinsame Arbeitsraum ohne weitere Schutzmassnahmen zulässig ist. Beim Zulieferer können beispielsweise Werkstückkanten, fallende Teile oder Quetschstellen relevant sein. Die Risikobeurteilung betrachtet auch Einrichten, Reinigung, Störungen, Wartung und Demontage, nicht nur den Normalbetrieb.

Ein KI-Planer ersetzt keine validierten Schutzfunktionen. Auch eine überzeugende Objekterkennung darf nicht als Ersatz für erforderliche Schutztechnik oder sichere Steuerung dienen. Geeignete Schutzfunktionen, deren Schnittstellen, sichere Betriebsarten sowie Stopp und Wiederanlauf müssen fachlich bestimmt und geprüft werden. Der Artikel gibt bewusst keine pauschalen Kraft- oder Geschwindigkeitsgrenzen vor; diese lassen sich nicht seriös unabhängig von der Anwendung festlegen.

Die zuständigen Fachpersonen bestimmen die anwendbaren Vorschriften und aktuellen Normenausgaben. Der industrielle Kontext der ISO 10218:2025 lässt sich nicht pauschal auf sämtliche mobilen, Service- oder humanoiden Systeme übertragen. Für exportierende Betriebe ergänzt unser Beitrag zur EU-Maschinenverordnung 2027 und Functional Safety die Einordnung. Offene sicherheitskritische Befunde bleiben eine Freigabesperre.

5. IT/OT-Zugriffe und Fernwartung bewusst begrenzen

Ein vernetzter Roboter ist auch ein IT/OT-System. Er benötigt eigene Identitäten und nur die Rechte, die für seine freigegebene Aufgabe erforderlich sind. Gemeinsame Admin-Konten und pauschale Schreibrechte im ERP sind keine zweckmässige Abkürzung. Netzplan, freigegebene Kommunikationswege, Authentifizierung und Protokollierung gehören in die Integrationsdokumentation.

Unser Zulieferer unterscheidet zwischen dem Lesen einer benötigten Prozessinformation und dem Ändern eines Produktionsauftrags. Eine Sprachaufforderung allein darf keine neuen Produktivänderungen auslösen. Fernwartung wird zeitlich und funktional begrenzt, ausdrücklich freigegeben und nachvollziehbar protokolliert. Wo unterstützt, stärkt Mehrfaktor-Authentifizierung den Zugang. Zugänge müssen widerrufbar bleiben, auch nach einem Anbieterwechsel.

Für Updates, Schlüssel, Sicherungen und Wiederherstellung braucht es Zuständigkeiten und überprüfte Verfahren. Das Team klärt ausserdem das Verhalten bei einem Netzwerkausfall. Eine Cloudverbindung darf weder Voraussetzung für fehlende Schutzfunktionen sein noch einen unkontrollierten Wiederanlauf ermöglichen. Verfügbarkeit und sicherer Zustand sind getrennte Anforderungen.

6. Datenflüsse nach DSG prüfen – einschliesslich Trainingsuploads

Kameras, Mikrofone, Karten und Protokolle können Mitarbeitende, Besucher oder vertrauliche Zeichnungen erfassen. Die Datenkarte beschreibt deshalb Inhalt, Zweck, Speicherort, Empfänger und Löschfrist: vom Sensor über lokale Verarbeitung bis zu Cloud, Support und Fernwartung. «Die KI läuft lokal» beantwortet nicht, ob Diagnosepakete oder Aufzeichnungen später das Unternehmen verlassen.

Beim hypothetischen Zulieferer prüft das Team, welche Daten überhaupt erforderlich sind und welche Aufzeichnungen deaktiviert werden können. Es klärt Informationen für betroffene Personen, Verträge zur Auftragsbearbeitung und allfällige Auslandsübermittlungen. Besonders wichtig: Darf der Anbieter Betriebsdaten für eigenes Modelltraining wiederverwenden? Vertragliche Aussagen und technische Einstellungen müssen zusammenpassen; ein unbeabsichtigter Trainingsupload ist kein akzeptabler Nebeneffekt.

Der EDÖB hält fest, dass das Schweizer Datenschutzgesetz direkt auf KI-gestützte Bearbeitungen von Personendaten anwendbar ist. Transparenz bleibt erforderlich. Kann eine geplante Bearbeitung ein hohes Risiko für Persönlichkeit oder Grundrechte mit sich bringen, ist eine Datenschutz-Folgenabschätzung (DSFA) durchzuführen. Das ist keine automatische Pflicht für jeden Roboter, aber eine Prüfung, die vor dem Einsatz erfolgen muss.

7. Im Pilot auch Fehler und menschliche Hilfe messen

Ein objektiver Pilot startet mit schriftlichen Akzeptanzkriterien und einer dokumentierten Ausgangslage des bisherigen Prozesses. Qualität, Zeit, Verfügbarkeit, Fehler, Abbrüche und menschliche Eingriffe werden getrennt erfasst. Ein erfolgreich bereitgestelltes Teil mit mehrfacher Hilfe ist nicht derselbe Erfolg wie ein autonom abgeschlossener Versuch. Misslungene Fälle dürfen nicht aus der Auswertung verschwinden.

Der fiktive Zulieferer nimmt repräsentative Teile, zulässige Varianten und unterschiedliche relevante Umgebungsbedingungen in den Testplan auf. Ungeeignete Fälle müssen ablehnbar oder an befugte Personen eskalierbar sein. Für seltene Fehler haben Simulation und geschützte Testumgebungen Vorrang. Dieser Artikel ist keine Bedienungsanleitung: Prüfungen an realen Robotern gehören ausschliesslich in die Hände befugter Fachpersonen mit geeigneten Schutzmassnahmen.

Jeder Versuch braucht eine eindeutige Konfiguration: Modell, Software, Hardware, Sensoren, Greifer sowie verwendete Regeln oder Prompts. Sonst bleibt unklar, welche Version eine Leistung tatsächlich erbracht hat. Für die organisatorische Planung hilft ergänzend unsere Checkliste «KI-Pilot in 90 Tagen». Physische Robotik verlangt darüber hinaus ihre eigene Sicherheitsprüfung.

Im Ergebnisbericht steht nicht nur eine Erfolgsquote, sondern auch, auf wie vielen Versuchen sie beruht und welche Fälle untersucht wurden. Assistenzzeit zählt als Aufwand, selbst wenn sie im Demonstrationsfilm unsichtbar bleibt. Das Team trennt Beobachtungen von Vermutungen: Ein störungsfreier Pilot beweist nicht, dass jeder seltene Fehler ausgeschlossen ist. Für ungeprüfte Varianten bleibt die Aussage begrenzt. Genau diese Ehrlichkeit macht die spätere Investitionsentscheidung belastbarer.

8. FAT, SAT und Betriebsfreigabe auseinanderhalten

Der Factory Acceptance Test (FAT) prüft vereinbarte Anforderungen beim Lieferanten; der Site Acceptance Test (SAT) prüft die Anwendung am Einsatzort. Gleichwertige dokumentierte Abnahmeverfahren sind ebenfalls möglich. Ein bestandener Lieferantentest ersetzt jedoch nicht die Standortprüfung: Beleuchtung, Schnittstellen, Verkehrswege und tatsächliche Arbeitsabläufe können sich unterscheiden.

Beim Zulieferer wird jede Abnahmeabweichung dokumentiert, zugeordnet und terminiert. Blockierende Befunde werden geschlossen und erneut geprüft, bevor die betriebliche Freigabe erfolgt. «Nicht anwendbar» braucht eine fachliche Begründung. Ein ausgefülltes Kästchen ohne passenden Nachweis belegt weder Sicherheit noch Datenschutz oder funktionierende Integration.

Das Abnahmeblatt der PDF-Vorlage bindet den Entscheid an Standort, Aufgabe, Einsatzgrenzen und Version. Möglich sind Freigabe im definierten Umfang, Nachbesserung mit Wiederprüfung oder kein Betrieb. Kein Go-live bei offenen blockierenden Sicherheits-, Datenschutz- oder Integrationsbefunden. Das Blatt ist keine Konformitätserklärung; Prüfberichte und weitere Nachweise werden separat aufbewahrt.

9. Das Team einführen und Änderungen kontrollieren

Mitarbeitende müssen Einsatzgrenzen, Zustandsanzeigen, Unsicherheit und Meldemöglichkeiten verstehen. Bedienung, Eingriffsrechte und Störungsbehebung werden geregelt und unterwiesen. Niemand soll improvisiert in einen Bewegungsbereich eingreifen, um eine Demonstration zu retten. Supportkontakte, Reaktionszeiten, Ersatzteile und ein tragfähiger manueller Ersatzprozess gehören zur Einführung.

Nach der Freigabe beobachtet der Zulieferer weiterhin Qualität, Ausfälle, Hilferufe und Beinaheereignisse. Meldungen dienen der Verbesserung, nicht der Schuldzuweisung. Wartung, Prüfintervalle und Review-Termine bleiben verbindlich. Die schriftliche Freigabe ist begrenzt und widerrufbar; sie erlaubt nicht jede künftig denkbare Aufgabe.

Neue Modelle, Software, Greifer, Standorte oder Datenquellen durchlaufen eine dokumentierte Änderungsbewertung mit nötigen Wiederprüfungen und Rückkehrmöglichkeit. Ungeprüftes Online-Lernen darf keine freigegebenen Bewegungen verändern. Neue Fähigkeiten gehören zuerst in einen geregelten Test- und Freigabepfad. Auch Anbieterwechsel und Stilllegung brauchen Vorbereitung: benötigte Konfigurationen sichern, Daten löschen, Zugänge widerrufen und fachgerechte Demontage planen.

Die 42 Checkpunkte im Projekt einsetzen

Die Vorlage gliedert sich in sechs Arbeitsblöcke. Auf jeder Seite helfen Nachweis-Hinweise und Verantwortlichkeitsfelder, aus einer Absicht eine überprüfbare Aufgabe zu machen:

ArbeitsblockCheckpunkte
Auftrag und Verantwortlichkeiten5
Anwendungssicherheit vor Autonomie7
Daten, IT/OT und Fernzugriff8
Pilot und Abnahme mit echten Fällen8
Einführung im Team und Betriebsfreigabe7
Laufender Betrieb und Änderungen7
Gesamt42

Starten Sie mit einem gemeinsamen Termin von Fachbereich, Projektleitung, IT/OT, Arbeitssicherheit und Integrator. Ordnen Sie offene Punkte zu, vereinbaren Sie benötigte Nachweise und halten Sie Datum sowie Visum fest. Die siebte Seite bündelt später den Abnahmeentscheid. Ziel ist nicht, möglichst rasch alle Kästchen anzukreuzen, sondern begründet entscheiden zu können: freigeben, nachbessern oder stoppen.

Jetzt die 7-seitige Praxischeckliste mit 42 Checkpunkten als PDF öffnen und speichern

Die beste Robotikintegration beginnt nicht mit maximaler Autonomie, sondern mit einer klaren Aufgabe, belastbaren Nachweisen und einem Team, das die Grenzen kennt.

Quellen und fachliche Orientierung

EDÖB: KI und Datenschutz, 24. September 2025 – DSG, Transparenz und DSFA bei hohen Risiken.
Suva: Robotik – Das Wichtigste in Kürze, Factsheet von 2018 – Integrationsgrundlagen und Robotikklassen, keine aktuelle Normenliste.
SICK: ISO 10218:2025 im industriellen Robotikkontext, 8. September 2025 – nicht pauschal auf humanoide oder andere Serviceroboter übertragbar.