Diese Beobachtung ist der Kern der Diskussion um Lark. In vielen mittelständischen Unternehmen setzt sich der Arbeitsalltag aus einem Messenger, einem Dateidienst, einem Konferenzwerkzeug, einem Aufgaben- oder Projektsystem, einer Tabellensammlung und einer Reihe kleiner Fachlösungen zusammen. Jedes Werkzeug ist für sich betrachtet gut, aber die Übergänge kosten Zeit, Aufmerksamkeit und Verlässlichkeit. Lark beantwortet dieses Problem nicht durch Integration, sondern durch Zusammenlegung: Eine Nachricht, ein Dokument, ein Datensatz, ein Termin und eine Genehmigung sind Objekte desselben Systems und lassen sich untereinander verlinken, einbetten und automatisieren, ohne dass eine Schnittstelle dazwischensteht.
Genauso wichtig ist die zweite Hälfte der Wahrheit. Lark wird von einem Unternehmen entwickelt und betrieben, das zum ByteDance-Konzern gehört — demselben Konzern, dem auch TikTok zugerechnet wird. Damit landet jede Bewertung von Lark unweigerlich in einer Debatte, die weit über Funktionsvergleiche hinausgeht: Es geht um Drittstaatentransfer, um staatliche Zugriffsbefugnisse, um politische Risikobewertung und um die Frage, welche Prozesse ein europäisches Unternehmen einem Anbieter mit chinesischem Konzernhintergrund überhaupt überlassen darf. Diesen Teil behandeln wir in Kapitel 09 ausführlich und ohne Beschönigung, weil er für die meisten Interessenten im DACH-Raum die eigentliche Entscheidungsfrage ist.
Technisch betrachtet ist die interessanteste Eigenschaft von Lark nicht die Menge der Module, sondern deren gemeinsame Grundlage. Ein Dokument ist kein Anhang, der in einem Chat auftaucht, sondern ein Objekt mit Rechten, Versionen und Kommentaren, das an beliebig vielen Stellen referenziert werden kann. Ein Datensatz aus der No-Code-Datenbank lässt sich in ein Dokument einbetten und bleibt dort lebendig. Eine Nachricht lässt sich in eine Aufgabe umwandeln, ohne dass Text kopiert wird. Ein Genehmigungsvorgang erscheint als Karte im Chat und wird dort entschieden, statt in einem separaten Portal.
Diese Objektgleichheit erklärt, warum die Suite oft als schnell empfunden wird, obwohl sie funktional breit ist: Der klassische Reibungsverlust entsteht weniger durch langsame Software als durch Kontextwechsel. Für die Bewertung heißt das, dass der Nutzen überproportional dann entsteht, wenn ein Unternehmen die Suite tatsächlich breit einsetzt. Wer Lark nur als Messenger neben einem vollständigen Microsoft-365-Stack betreibt, zahlt Komplexität, ohne den Integrationsvorteil einzulösen.
Für einen Anbieter mit vergleichsweise geringer Präsenz im deutschsprachigen Markt tauchen Lark und der chinesische Zwilling Feishu in Beratungsgesprächen erstaunlich häufig auf. Dafür gibt es typischerweise drei Auslöser. Der erste ist ein Geschäftsbezug nach Asien: Ein Unternehmen importiert, produziert oder vertreibt in China, Singapur, Japan oder Südostasien, und die Partner auf der anderen Seite arbeiten selbstverständlich in Feishu oder Lark. Die Alternative wäre, Lieferanten in ein westliches Werkzeug zu zwingen, was in der Praxis oft misslingt.
Der zweite Auslöser ist der Preis. Lark tritt mit einer großzügig ausgestatteten kostenfreien Stufe und aggressiv kalkulierten bezahlten Editionen an, was für kostenbewusste Organisationen attraktiv wirkt — insbesondere im Vergleich mit der Summe aus Messenger, Dateidienst, Konferenzwerkzeug und Datenbanklösung. Der dritte Auslöser ist Frustration über Fragmentierung: Wer in seinem Haus fünf Werkzeuge zählt, die dasselbe halb können, findet die Idee einer einzigen Oberfläche naturgemäß verlockend.
Alle drei Motive sind legitim. Keines davon ersetzt die Prüfung, die in Kapitel 09 beschrieben wird. Unsere Erfahrung ist, dass Unternehmen, die Lark aus dem ersten Motiv heraus einführen, damit meist zufrieden werden, weil ein konkreter Bedarf dahintersteht. Unternehmen, die aus dem zweiten Motiv heraus wechseln, unterschätzen oft die Kosten der Migration, der Schulung und der datenschutzrechtlichen Absicherung — und stellen fest, dass die vermeintliche Ersparnis an anderer Stelle wieder ausgegeben wird.
Zur Einordnung gehört auch die Abgrenzung nach unten und nach oben. Lark ist kein klassisches Projektmanagement-Werkzeug im Sinne einer tiefen Terminplanung mit Netzplantechnik, Ressourcennivellierung und Meilensteintrendanalyse. Es gibt Aufgaben, Projektansichten und über die No-Code-Datenbank sehr flexible Strukturen, aber wer Abhängigkeiten rechnen, Kapazitäten simulieren und Portfolios auswerten will, arbeitet mit spezialisierten Plattformen präziser.
Lark ist außerdem kein ERP und kein Dokumentenmanagementsystem mit revisionssicherer Archivierung im Sinne der handels- und steuerrechtlichen Aufbewahrungspflichten. Die Suite verwaltet Arbeitsdokumente, keine Belegarchive. Und Lark ist kein selbst betreibbares System: Für den europäischen Markt handelt es sich um ein reines Cloud-Angebot ohne Installation im eigenen Rechenzentrum. Wer Datenhoheit über technische Kontrolle herstellen will, findet diesen Weg hier nicht — was für einen Teil der Interessenten das Thema schon an dieser Stelle beendet.
Feishu ist die ursprünglich für den chinesischen Markt entwickelte Suite; sie entstand als internes Werkzeug innerhalb des ByteDance-Konzerns und wurde später als Produkt vermarktet. Lark ist das internationale Angebot, das über eine eigene Gesellschaft mit Sitz in Singapur vertrieben und betrieben wird. Beide teilen die grundlegende Produktarchitektur und einen großen Teil der Funktionslogik, unterscheiden sich aber in Oberfläche, Sprachumfang, verfügbaren Modulen, Integrationskatalog, Vertragspartner, Betriebsregionen und Zahlungsabwicklung.
Für Unternehmen im DACH-Raum ist die Unterscheidung praktisch relevant, weil sie in drei Situationen aufeinandertreffen. Erstens: Ein deutsches Unternehmen nutzt Lark, der chinesische Partner nutzt Feishu — dann ist genau zu klären, ob und wie beide Welten miteinander kommunizieren können, welche Funktionen dabei entfallen und wo die Daten der Zusammenarbeit liegen. Zweitens: Eine Konzernmutter in Asien gibt die Suite vor, und die europäische Tochter muss beurteilen, ob sie die Vorgabe rechtlich umsetzen kann. Drittens: Recherchen im Internet vermischen beide Produkte, sodass Funktions- und Preisangaben aus dem chinesischen Markt für Lark falsch sind. Wir empfehlen, in jeder Anfrage an den Anbieter ausdrücklich zu benennen, über welches der beiden Produkte gesprochen wird, und die Antwort schriftlich zu erhalten.
Es hilft niemandem, den Konzernhintergrund zu verschweigen oder zu relativieren. Lark gehört zum ByteDance-Konzern, einem der größten Technologieunternehmen mit Ursprung in der Volksrepublik China, dessen bekanntestes Produkt TikTok ist. Der Konzern ist international verschachtelt aufgestellt, mit Gesellschaften in Singapur, den USA, Europa und China. Aus dieser Struktur folgt keine automatische Aussage über die Sicherheit einer konkreten Datenverarbeitung — aber sie erzeugt eine Prüfpflicht, die bei einem europäischen oder US-amerikanischen Anbieter anders aussieht.
Zwei Missverständnisse sollten dabei vermieden werden. Das erste: Lark ist nicht TikTok. Es handelt sich um unterschiedliche Produkte, Zielgruppen, Datenarten und teils unterschiedliche Betriebsgesellschaften; Erkenntnisse aus der TikTok-Debatte lassen sich nicht ungeprüft übertragen. Das zweite: Die Konzernzugehörigkeit ist gleichwohl kein Nebenaspekt, weil aufsichtsbehördliche und politische Bewertungen häufig auf Konzernebene ansetzen und weil die Frage nach Zugriffsmöglichkeiten verbundener Unternehmen ein Standardpunkt jeder Risikoanalyse ist. Beides gleichzeitig auszuhalten — differenzieren und trotzdem streng prüfen — ist die einzige seriöse Haltung.
Der Anbieter staffelt sein Angebot in mehrere Stufen, deren Namen und Zuschnitt sich über die Jahre verändert haben. Verlässlich ist das Muster: eine kostenfreie Einstiegsstufe mit überraschend vollständigem Funktionsumfang bei begrenzter Nutzerzahl, begrenztem Speicher, begrenzter Konferenzdauer und begrenzten Administrationsmöglichkeiten. Darüber liegen eine oder mehrere Professional-Stufen, die Speicher, Konferenzkomfort, Automatisierungsvolumen, Analysefunktionen und Administrationstiefe erweitern. Die oberste Unternehmensstufe adressiert Sicherheits-, Compliance- und Verwaltungsanforderungen: Anbindung an die Identitätsverwaltung, feingranulare Richtlinien, erweiterte Protokollierung, Aufbewahrungs- und Exportregeln, gegebenenfalls Optionen zur Datenresidenz und vertragliche Zusatzvereinbarungen.
Für die Budgetplanung ist die entscheidende Frage nicht der Listenpreis, sondern die Stufenzuordnung der Funktionen, die den Wechsel motivieren. Wer sich für Lark interessiert, weil die No-Code-Datenbank, die Genehmigungsprozesse und die Übersetzungsfunktionen im Chat überzeugen, sollte vor der Entscheidung schriftlich bestätigt bekommen, in welcher Stufe diese Fähigkeiten in welchem Umfang enthalten sind, welche Volumengrenzen gelten und wie sich die Konditionen bei Verlängerung entwickeln. Diese Prüfung kostet einen Termin und erspart im Zweifel eine Fehlentscheidung.
Der Messenger ist das Herz der Suite und funktional deutlich weiter gefasst als ein klassischer Team-Chat. Er kennt Einzel- und Gruppenunterhaltungen, Themen-Kanäle, Threads, Reaktionen, Erwähnungen, geplante Nachrichten, Lesebestätigungen und die Möglichkeit, eine Nachricht direkt in eine Aufgabe, einen Kalendereintrag oder einen Dokumentabschnitt zu überführen. Bemerkenswert sind zwei Eigenschaften: erstens die tief eingebaute maschinelle Übersetzung, die Nachrichten und in Teilen auch Dokumente zwischen den Arbeitssprachen der Beteiligten überträgt und damit gemischtsprachige Teams spürbar entlastet; zweitens die Karten- und Bot-Struktur, über die Genehmigungen, Formulare, Umfragen und externe Systemmeldungen als bedienbare Elemente im Gesprächsverlauf erscheinen.
Aus Sicht der Betriebsführung ist wichtig, dass der Messenger als Kommunikationssystem im Sinne der Aufbewahrung, der Mitbestimmung und der Datenschutzfolgenabschätzung zu behandeln ist. Wo Übersetzungsdienste, Suchindizes und Vorschaufunktionen Inhalte verarbeiten, entstehen Verarbeitungsvorgänge, die zu dokumentieren sind. Das gilt für jedes Werkzeug dieser Art, bei einem Anbieter mit Drittstaatenbezug aber mit höherer Sorgfaltsanforderung.
Das Wiki dient als strukturierter Wissensraum mit Baumnavigation, Berechtigungen und Suche. In der Praxis ist die gemeinsame Suche über Chat, Dokumente, Wiki und Datenbank einer der am häufigsten gelobten Aspekte — allerdings auch einer der sensibelsten, weil eine gute Suche jede Nachlässigkeit im Rechtekonzept sofort sichtbar macht.
Der praktische Wert liegt darin, dass Fachbereiche kleine Anwendungen bauen können, ohne die IT zu belasten: eine Lieferantenübersicht mit Bemusterungsstatus, ein Reklamationsregister, eine Maschinenwartungsliste, eine Messeplanung mit Aufgaben und Terminen, eine Bewerberpipeline. Weil Base im gleichen System wie Chat und Dokumente liegt, entstehen Rückmeldungen ohne Medienbruch: Ein neuer Datensatz erzeugt eine Karte im zuständigen Kanal, ein Statuswechsel löst eine Genehmigung aus, eine Sicht wird in ein Wochenprotokoll eingebettet.
Die Kehrseite kennt jeder, der No-Code-Plattformen begleitet hat: Ohne Regeln entsteht eine Schattenanwendungslandschaft. Wer Base freigibt, sollte gleichzeitig festlegen, welche Datenarten dort nichts zu suchen haben — insbesondere besondere Kategorien personenbezogener Daten, Gesundheits-, Bewerber- und Vergütungsdaten —, wer für eine Basis verantwortlich ist, wie exportiert wird und was beim Ausscheiden der erstellenden Person passiert.
Der Kalender bringt geteilte Kalender, Verfügbarkeitsansichten, Ressourcen- und Raumbuchung, Terminvorschläge über Zeitzonen hinweg sowie die Verknüpfung von Terminen mit Dokumenten und Konferenzen. Approval ist das Modul für Genehmigungsprozesse: Formulare, mehrstufige Freigabepfade mit Bedingungen, Vertretungsregeln, Fristen, Eskalationen und eine nachvollziehbare Historie. Urlaubsanträge, Beschaffungen, Reisekosten, Vertragsfreigaben und Investitionsanträge lassen sich damit ohne Programmierung abbilden — für viele Unternehmen der Baustein mit dem schnellsten sichtbaren Effekt, weil er Papier und Mailketten ersetzt.
Mail stellt ein Postfach mit eigener Domain bereit und schließt die Suite nach außen. In der Praxis ist dies der Baustein, den europäische Unternehmen am seltensten migrieren, weil die E-Mail-Infrastruktur meist tief in bestehende Systeme, Archivierungspflichten und Signaturlösungen eingebettet ist. Die Personalmodule schließlich decken Organisationsverzeichnis, Anwesenheits- und Zeiterfassung, Abwesenheitsverwaltung, Onboarding-Abläufe und je nach Ausbaustufe weitere Personalprozesse ab. Genau hier ist besondere Zurückhaltung angebracht: Zeiterfassung und Anwesenheitsdaten sind mitbestimmungspflichtig und hochsensibel; sie in einem Drittstaatenkontext zu führen, ist eine Entscheidung, die eine dokumentierte Abwägung verlangt und die wir für den DACH-Raum in der Regel nicht empfehlen.
Die Automatisierung folgt dem Muster, das sich in modernen Arbeitsplattformen durchgesetzt hat: Ein Auslöser tritt ein, eine Bedingung wird geprüft, eine Aktion wird ausgeführt. Auslöser sind unter anderem neue oder geänderte Datensätze in Base, eingehende Formulare, Statuswechsel, Zeitpunkte und Fristen, Nachrichten mit bestimmten Merkmalen oder Ereignisse aus angebundenen Systemen. Aktionen reichen von Benachrichtigungen in Chat und Kanal über das Anlegen von Aufgaben, Terminen und Datensätzen bis zum Start eines Genehmigungsvorgangs oder dem Aufruf einer externen Schnittstelle.
In der Praxis entstehen daraus die Abläufe, die den Alltag entlasten: Eine Reklamation, die über ein Formular eingeht, erzeugt einen Datensatz, benachrichtigt den zuständigen Kanal, legt eine Aufgabe mit Frist an und eskaliert bei Überschreitung an die Leitung. Eine Beschaffungsanfrage über einem definierten Betrag läuft automatisch in eine zweite Genehmigungsstufe. Ein neuer Mitarbeiter löst eine Onboarding-Kette mit Aufgaben für IT, Personal und Fachbereich aus. Solche Abläufe sind der Ort, an dem sich eine All-in-One-Suite wirklich auszahlt, weil sie ohne Schnittstellen zwischen Systemen funktionieren.
Für den Betrieb gilt eine einfache Regel: Automatisierung erst dann, wenn Struktur und Datenpflege stehen — und zu jedem Ablauf gehört eine dokumentierte Verantwortlichkeit.
Der Anbieter bündelt seine KI-Fähigkeiten unter eigenen Bezeichnungen, deren Umfang, Verfügbarkeit und Editionsbindung sich schnell weiterentwickeln. Inhaltlich bewegen sie sich in den Kategorien, die in der Branche üblich sind: Zusammenfassung langer Gesprächsverläufe, Dokumente und Konferenzmitschriften; Übersetzung in hoher Qualität und in die Oberfläche eingebaut; Entwurfsunterstützung beim Schreiben und Umformulieren; Suche und Fragen an eigene Inhalte, also die Möglichkeit, in natürlicher Sprache Antworten aus Dokumenten, Wiki und Datenbanken zu erhalten; Datenarbeit in Base, etwa das Erzeugen von Feldern, Formeln oder Ansichten aus einer Beschreibung; und Assistenten beziehungsweise Agenten, die Aufgaben über mehrere Schritte hinweg ausführen.
Für die Bewertung sind drei Fragen wichtiger als jede Funktionsliste. Erstens: Welche Modelle werden verwendet und wo werden sie betrieben? Bei einem Anbieter aus dem ByteDance-Umfeld ist die naheliegende Annahme, dass konzerneigene Modelle eine Rolle spielen; welche Modelle für welche Funktion, in welcher Region und mit welchen Unterauftragsverarbeitern eingesetzt werden, ist konkret zu erfragen und schriftlich zu dokumentieren. Zweitens: Werden Eingaben zum Training verwendet? Hier ist eine vertragliche Zusicherung erforderlich, keine Aussage aus einer Marketingseite. Drittens: Lassen sich KI-Funktionen zentral und granular abschalten? Eine Suite, in der Administratoren KI je Funktion, je Gruppe und je Datenraum steuern können, ist wesentlich leichter freizugeben als eine, in der nur ein globaler Schalter existiert.
Ein Bereich verdient besondere Aufmerksamkeit, weil er im Alltag schnell zur Gewohnheit wird: die automatische Aufzeichnung und Verschriftung von Besprechungen. Der Nutzen ist offensichtlich — Beschlüsse sind belegt, Aufgaben werden nicht vergessen, Abwesende können nachlesen, und über Sprachgrenzen hinweg entsteht ein gemeinsames Protokoll. Gleichzeitig entstehen Sprachaufnahmen und Transkripte von Beschäftigten, in denen beiläufig Bewertungen, Gesundheitshinweise, Konflikte und Vertragsinterna auftauchen.
Wer diese Funktion einsetzt, braucht klare Regeln: transparente Ankündigung und Zustimmung, Beschränkung auf definierte Besprechungsarten, kurze Aufbewahrungsfristen, engen Zugriffskreis, Verbot der Leistungsbewertung, Beteiligung des Betriebsrats und eine Datenschutzfolgenabschätzung, wenn die Verarbeitung umfangreich ist. In Kombination mit einem Anbieter im Drittstaatenkontext ist dies der Punkt, an dem wir am häufigsten empfehlen, die Funktion entweder ganz abzuschalten oder auf unkritische Formate zu begrenzen.
Die Entwicklerplattform des Anbieters stellt die üblichen Bausteine bereit. Über offene Schnittstellen lassen sich Nutzer und Organisationsstruktur, Nachrichten, Dokumente, Kalender, Aufgaben, Genehmigungen und Datenbankinhalte lesen und schreiben. Bots agieren als eigenständige Teilnehmer in Unterhaltungen und können strukturierte Karten senden, Eingaben aufnehmen und Rückfragen stellen. Webhooks und Ereignisabonnements erlauben es, auf Vorgänge in der Suite zu reagieren oder von außen Meldungen einzuspeisen. Über die Verwaltung lassen sich eigene Anwendungen für das Unternehmen registrieren, mit definierten Berechtigungen versehen und gezielt an Gruppen ausrollen.
Ergänzend existiert ein Verzeichnis fertiger Erweiterungen für gängige Aufgaben, und für Automatisierung über Systemgrenzen hinweg bietet der Anbieter eine eigene Integrationsplattform mit visuellen Ablaufketten an. Für Häuser mit eigener Entwicklungskapazität ist das Angebot gut dokumentiert und arbeitsfähig.
Die Grenzen zeigen sich weniger an der Schnittstelle als am Katalog. Der typische DACH-Mittelstand betreibt ein Warenwirtschafts- oder ERP-System aus dem deutschsprachigen Raum, eine Finanzbuchhaltung mit etablierter Steuerberatungsschnittstelle, ein CRM aus dem europäischen oder US-Markt, eine Zeitwirtschaft mit Tarifbezug, ein Dokumentenarchiv mit Aufbewahrungspflichten, ein Personalsystem mit deutscher Lohnabrechnung und eine Reihe branchenspezifischer Fachlösungen. Für diese Systeme existieren im Ökosystem westlicher Suiten seit Jahren fertige Anbindungen, Partnerlandschaften und dokumentierte Referenzen; im Lark-Umfeld sind sie deutlich seltener.
Das bedeutet nicht, dass eine Anbindung unmöglich ist — über Schnittstellen, Webhooks und Automatisierungsdienste lässt sich fast alles verbinden. Es bedeutet aber, dass die Integrationsarbeit ins Projekt gehört und nicht in eine Klickstrecke. Wer Lark einführt, sollte mit einem eigenen Aufwandsblock für Anbindungen rechnen und die drei bis fünf Systeme benennen, deren Verbindung geschäftskritisch ist. Diese Systeme gehören in einen Machbarkeitstest, bevor eine Lizenzentscheidung fällt.
Ein zweiter Reibungspunkt ist die Koexistenz mit vorhandenen Stacks. Sehr viele Unternehmen im DACH-Raum arbeiten mit Microsoft 365 als Grundlage; Identitäten, Postfächer, Dateien, Berechtigungen und Sicherheitsrichtlinien hängen daran. Lark daneben zu betreiben, erzeugt eine zweite Identitäts- und Datenwelt. Der Anbieter unterstützt Anbindungen an Identitätsverwaltungen und Verzeichnisdienste, sodass die Anmeldung vereinheitlicht werden kann; die inhaltliche Doppelung von Dateien, Kalendern und Chats lässt sich damit aber nicht auflösen. Entweder man entscheidet sich für eine Leitplattform und definiert für die zweite einen engen Zweck, oder man akzeptiert dauerhafte Doppelpflege. Beides ist vertretbar, aber nur bewusst entschieden.
Bei einem Punkt ist das Ökosystem von Lark den westlichen Suiten überlegen: der Zusammenarbeit mit Partnern, die selbst in Lark oder Feishu arbeiten. Wo ein Lieferant in Shenzhen, ein Handelsvertreter in Singapur und ein Prüfdienstleister in Japan bereits in dieser Welt zu Hause sind, entfällt der übliche Reibungsverlust: keine Gastkonten mit halben Rechten, keine Dateien per Mailanhang, keine Terminabstimmung über drei Kalendersysteme. Genau in dieser Konstellation entsteht der belastbarste Geschäftsnutzen — und genau daran sollte die Entscheidung für die Suite auch bemessen werden. Wer keinen solchen Partnerkreis hat, verliert diesen Vorteil und behält die Nachteile.
Gegen Microsoft sprechen aus Sicht von Lark-Interessenten vor allem drei Punkte: die Fragmentierung innerhalb der eigenen Produktfamilie mit Überlappungen zwischen mehreren Werkzeugen für dieselbe Aufgabe, die Abhängigkeit von einem sehr großen Anbieter und die Kostenentwicklung bei höheren Editionen. Unsere nüchterne Einordnung: Wer bereits in Microsoft 365 arbeitet und keinen zwingenden Asien-Bezug hat, findet in Lark keinen Grund für einen Wechsel, der die Migrations-, Schulungs- und Compliance-Kosten aufwiegt.
Google Workspace ist der nächste Verwandte im Konzept: eine integrierte Suite mit Mail, Kalender, Dokumenten, Tabellen, Videokonferenz und Dateiablage, stark in Echtzeit-Zusammenarbeit und Bedienbarkeit. Lark ist funktional breiter, weil es Genehmigungen, eine No-Code-Datenbank und Personalmodule mitbringt, für die man bei Google auf Zusatzwerkzeuge ausweicht. Google punktet mit Marktreife, Partnerlandschaft, europäischen Rechenzentren und einem Vertragswerk, das in europäischen Prüfungen etabliert ist.
Der Verzicht auf eine On-Premises-Variante hat zwei Seiten. Positiv: Es entfällt der Aufwand für Server, Aktualisierungen, Sicherungen, Verfügbarkeit und Skalierung; neue Funktionen kommen ohne Projekt; die mobilen Anwendungen sind ohne zusätzliche Infrastruktur nutzbar, was für Außendienst, Produktion und Logistik ein echter Vorteil ist. Negativ: Es gibt keinen technischen Weg, Datenhoheit durch eigene Kontrolle herzustellen. Wer aus regulatorischen oder strategischen Gründen verlangt, dass bestimmte Daten das eigene Rechenzentrum oder den europäischen Rechtsraum nicht verlassen, kann dies bei Lark nicht durch Architektur lösen, sondern nur durch Beschränkung des Einsatzbereichs — oder durch die Wahl eines anderen Anbieters.
Ebenso zu bedenken: Bei einer Suite, die Kommunikation, Dokumente, Prozesse und Personaldaten in einem System hält, ist die Abhängigkeit größer als bei einem Einzelwerkzeug. Eine Ausstiegsstrategie ist deshalb kein Formalismus. Vor dem Produktivstart sollte geklärt und getestet sein, in welchen Formaten Dokumente, Datenbanken, Chatverläufe, Genehmigungshistorien und Anwesenheitsdaten exportierbar sind, wie lange ein vollständiger Export dauert, welche Metadaten dabei verloren gehen und wie lange Daten nach Vertragsende verfügbar bleiben. Ein Exporttest mit echten Inhalten sagt mehr als jede Zusicherung.
Die Verwaltung erfolgt über eine zentrale Administrationskonsole, die die Organisationsstruktur, Nutzer und Gruppen, Rollen und Berechtigungen, Sicherheitsrichtlinien, Freigabe- und Gastregeln, Anwendungsverwaltung, Aufbewahrungs- und Exporteinstellungen sowie Auswertungen zur Nutzung bündelt. Wichtig für die Einführung ist, dass die Organisationsstruktur in Lark nicht nur ein Adressbuch ist: Sie steuert Sichtbarkeiten, Genehmigungspfade, Vertretungen und Kalenderrechte. Ein sauber gepflegtes Organigramm ist damit Voraussetzung, nicht Ergebnis der Einführung.
Beim Rechtekonzept empfehlen wir konsequente Sparsamkeit. Konkret: Zugriffe über Gruppen statt über Einzelpersonen vergeben; für externe Beteiligte klar abgegrenzte Räume mit Ablaufdatum statt dauerhafter Gastkonten; Freigabelinks nur eingeschränkt zulassen und nie ohne Ablauf; administrative Rollen aufteilen, sodass nicht eine Person alles darf; die Anmeldung über die vorhandene Identitätsverwaltung mit Mehrfaktorauthentifizierung anbinden; und für sensible Bereiche wie Personal, Recht und Geschäftsführung von Anfang an entscheiden, ob sie überhaupt in dieser Suite geführt werden sollen. Der letzte Punkt ist der wichtigste, weil er sich später nur mit erheblichem Aufwand korrigieren lässt.
Ein häufig unterschätzter Punkt: Lark ist ein international ausgerichtetes Produkt mit Schwerpunkt in Asien. Für den DACH-Raum ergeben sich daraus praktische Fragen, die vor der Entscheidung geklärt werden sollten. Wie vollständig ist die deutschsprachige Oberfläche, und gilt das auch für Verwaltungsbereiche, Fehlermeldungen und Hilfetexte? In welcher Sprache und zu welchen Zeiten ist der Support erreichbar, mit welchen Reaktionszeiten, und gibt es deutschsprachige Ansprechpartner für Vertrag, Datenschutz und Eskalation? Existiert eine Partnerlandschaft im deutschsprachigen Raum für Einführung, Schulung und Betrieb, oder ist das Unternehmen auf eigene Kräfte angewiesen? Wie sind Dokumentation und Schulungsmaterial auf Deutsch verfügbar, gerade für Mitarbeitende ohne Englischkenntnisse?
Unsere Erfahrung: Die Antworten sind für Lark deutlich dünner als für die etablierten westlichen Suiten. Das ist kein Ausschlussgrund, aber ein Kostenfaktor, der in die Kalkulation gehört. Wo Produktion, Lager oder Handwerk beteiligt sind und die Belegschaft sprachlich heterogen ist, entscheidet die Qualität der deutschsprachigen Materialien maßgeblich über die Akzeptanz.
Wenn die Anbieterentscheidung dokumentiert getroffen ist, hat sich in Projekten folgende Reihenfolge bewährt.
Allen drei Szenarien ist ein konkreter, benennbarer Vorteil gemeinsam, der über „alles an einem Ort“ hinausgeht. Wo er fehlt, bleibt nur die Aufräumhoffnung — und die erfüllt sich auch mit einer europäischen Lösung, meist mit weniger Prüfaufwand.
Es gibt Konstellationen, in denen wir von Lark abraten, und zwar nicht aus Vorsicht, sondern aus konkreten Gründen. Erstens: überall dort, wo besonders schutzbedürftige Daten den Kern des Geschäfts bilden — Gesundheitsdaten, Sozialdaten, Mandats- und Berufsgeheimnisse bei Ärzten, Anwälten, Steuerberatern, Kliniken, Sozialträgern und Bildungseinrichtungen. Die Kombination aus Berufsgeheimnis, Drittstaatentransfer und fehlendem Angemessenheitsbeschluss lässt sich hier nicht sauber auflösen.
Zweitens: bei Unternehmen mit öffentlichen Auftraggebern, mit Bezug zu kritischer Infrastruktur, mit Sicherheitsanforderungen aus Kunden- oder Behördenverträgen oder mit Rüstungs- und Dual-Use-Berührung. Hier existieren häufig vertragliche Vorgaben zu Anbieterherkunft und Datenstandorten, und die politische Debatte über Dienste aus dem ByteDance-Umfeld führt regelmäßig zu Nachfragen, die man sich ersparen kann.
Drittens: in Unternehmen, deren wertvollstes Gut technisches Wissen ist — Konstruktionsdaten, Rezepturen, Verfahrensbeschreibungen, Quellcode, Preis- und Kalkulationslogik — und die gleichzeitig im Wettbewerb mit asiatischen Marktteilnehmern stehen. Unabhängig von jeder rechtlichen Bewertung ist es eine strategische Frage, wo dieses Wissen liegt; sie sollte von der Geschäftsführung entschieden und nicht in einer Werkzeugauswahl beiläufig mitgetroffen werden.
Viertens: in Häusern, die vollständig und zufrieden in Microsoft 365 arbeiten. Hier ist der Wechsel selten wirtschaftlich. Fast immer lässt sich das eigentliche Problem — Werkzeugwildwuchs, unklare Zuständigkeiten, fehlende Prozesse — mit Ordnung im vorhandenen Stack lösen, und das zu einem Bruchteil der Kosten einer Migration.
Zur Kostenseite lassen sich ohne Preisangaben belastbare Aussagen treffen. Die Lizenzkosten folgen dem üblichen Muster der Abrechnung pro Nutzer und Monat oder Jahr, gestaffelt nach Edition, mit einer kostenfreien Einstiegsstufe und Zusatzmodulen für Speicher, KI und Personalfunktionen. Bemerkenswert ist, dass Lark im Marktvergleich als preisaggressiv gilt — was für die Entscheidung genau deshalb gefährlich ist: Der Lizenzpreis ist bei einer Suite dieser Art selten der bestimmende Kostenblock.
In Summe heißt das: Wer Lark ausschließlich als günstigere Alternative rechnet, rechnet falsch. Der Lizenzvorteil wird durch Einführungs-, Integrations- und insbesondere Compliance-Aufwand relativiert. Wirtschaftlich attraktiv ist die Suite dort, wo sie ein echtes Problem löst, nicht dort, wo sie Lizenzkosten senkt.
Die Verarbeitung personenbezogener Daten außerhalb des Europäischen Wirtschaftsraums ist nach Kapitel V der DSGVO nur unter besonderen Bedingungen zulässig. Für einige Länder hat die Europäische Kommission einen Angemessenheitsbeschluss erlassen, der den Transfer erleichtert. Für die Volksrepublik China existiert kein solcher Beschluss. Transfers müssen daher auf einem anderen Instrument beruhen, in der Praxis nahezu immer auf den Standardvertragsklauseln der Kommission.
Seit der Schrems-II-Entscheidung des Europäischen Gerichtshofs genügt es nicht, diese Klauseln zu unterzeichnen. Der Verantwortliche muss zusätzlich prüfen, ob das Recht des Empfängerlandes ein Schutzniveau erlaubt, das dem europäischen im Wesentlichen gleichwertig ist — und, falls nicht, ergänzende Maßnahmen ergreifen. Diese Prüfung ist das Transfer Impact Assessment. Sie ist zu dokumentieren, muss die konkrete Verarbeitung betrachten und bei geänderter Lage aktualisiert werden.
Für China ist die Prüfung anspruchsvoll, weil der dortige Rechtsrahmen umfassende Mitwirkungs- und Auskunftspflichten gegenüber staatlichen Stellen vorsieht. Genannt werden in der Fachdiskussion regelmäßig das Nationale Geheimdienstgesetz, das Cybersicherheitsgesetz, das Datensicherheitsgesetz und das Gegenspionagegesetz; hinzu kommt mit dem Gesetz zum Schutz personenbezogener Informationen ein Datenschutzrecht, das inhaltlich Anleihen an die DSGVO nimmt, den staatlichen Zugriff aber nicht in vergleichbarer Weise begrenzt. Charakteristisch sind aus europäischer Sicht die weite Fassung von Sicherheitsinteressen, die eingeschränkte gerichtliche Kontrolle, die begrenzte Transparenz gegenüber Betroffenen und das Fehlen wirksamer Rechtsschutzmöglichkeiten für Personen in der EU. Genau diese Punkte sind die Maßstäbe, an denen Schrems II ein Drittland misst.
Wichtig ist dabei ein Zwischenschritt, der oft übersprungen wird: Maßgeblich ist nicht allein, wo die Server stehen, sondern wer Zugriff hat und welchem Recht dieser Zugreifende unterliegt. Eine Datenhaltung in Singapur oder Europa hilft nur, wenn nicht gleichzeitig Verwaltungs-, Entwicklungs-, Support- oder Konzernstellen aus China auf Inhalte, Metadaten oder Protokolle zugreifen können. Diese Frage nach den Zugriffspfaden — Support mit Einsicht in Inhalte, Entwicklungszugriffe, Fernwartung, konzerninterne Auswertung, Unterauftragsverarbeiter — ist der Kern jeder ernsthaften Prüfung.
Der Anbieter benennt regionale Betriebsoptionen für das internationale Produkt und trennt es organisatorisch vom chinesischen Angebot. Welche Regionen für welche Editionen, welche Module und welche Datenarten konkret zur Verfügung stehen, verändert sich und lässt sich nur beim Anbieter selbst verbindlich klären. Wir empfehlen ausdrücklich, sich hier nicht auf Marketingaussagen oder Sekundärquellen zu verlassen, sondern eine schriftliche, auf den Vertragsgegenstand bezogene Auskunft einzuholen — und zwar zu folgenden Punkten.
Zur ehrlichen Bewertung gehört, dass Dienste aus dem ByteDance-Umfeld seit Jahren Gegenstand einer intensiven politischen und aufsichtsrechtlichen Auseinandersetzung sind. Europäische Institutionen und mehrere Mitgliedstaaten haben die Nutzung von TikTok auf Diensttelefonen untersagt oder beschränkt; in den Vereinigten Staaten und weiteren Ländern gab und gibt es weitreichende gesetzgeberische Vorstöße; europäische Datenschutzaufsichtsbehörden haben Datenflüsse in Richtung China untersucht und beanstandet, und der Konzern hat mit eigenen Programmen zur lokalen Datenhaltung in Europa reagiert.
Diese Vorgänge betreffen unmittelbar ein anderes Produkt als Lark, und es wäre unsauber, sie gleichzusetzen. Für ein europäisches Unternehmen sind sie dennoch relevant, und zwar aus drei Gründen. Erstens argumentieren Aufsichtsbehörden bei Transferfragen regelmäßig auf Ebene der Konzernstruktur und der anwendbaren Rechtsordnung, nicht auf Ebene einzelner Apps. Zweitens erhöht die öffentliche Aufmerksamkeit die Wahrscheinlichkeit, dass eine Prüfung tatsächlich stattfindet — durch Behörden, durch Kunden im Rahmen von Lieferantenaudits, durch Auftraggeber der öffentlichen Hand oder durch Versicherer. Drittens ist Reputation ein eigener Faktor: Die Frage, warum die interne Kommunikation über einen Anbieter mit chinesischem Konzernhintergrund läuft, kann in einer Ausschreibung, einem Kundenaudit oder einer Betriebsversammlung gestellt werden, und man sollte eine dokumentierte Antwort haben.
In Betrieben mit Betriebsrat ist die Einbindung in Deutschland bei Lark deutlicher erforderlich als bei einem reinen Aufgabenwerkzeug, weil zu den Kernfunktionen Anwesenheits- und Zeiterfassung, Lesebestätigungen, Nutzungsauswertungen, Konferenzaufzeichnungen und Transkripte gehören. Maßgeblich ist die Mitbestimmung bei technischen Einrichtungen, die zur Überwachung von Verhalten oder Leistung geeignet sind, nach § 87 BetrVG. Sinnvoll ist eine frühe Abstimmung vor der Konfiguration und eine Betriebsvereinbarung, die Auswertungen, Aggregationsebene, Einsichtsrechte, Aufbewahrungsfristen und den Ausschluss individueller Leistungsbewertung regelt. Für Österreich und die Schweiz gelten eigene Regelungen mit vergleichbarer Zielrichtung. Auch dies ist keine Rechtsberatung.
Für Lark bleibt damit ein klar umgrenzter, sinnvoller Platz: als Brücke nach Asien. Wo Lieferanten, Partner, Tochtergesellschaften oder Kunden in dieser Welt arbeiten, ist eine bewusst begrenzte, dokumentierte und mit Negativliste versehene Nutzung eine tragfähige Entscheidung — häufig tragfähiger als der Versuch, alle Beteiligten in ein westliches Werkzeug zu zwingen. Zwei Umgebungen mit klarer Aufgabenteilung sind in diesem Fall nicht Fragmentierung, sondern Risikosteuerung. Und die Entscheidung darüber gehört auf die Ebene der Geschäftsführung, mit einer schriftlichen Begründung, die auch in zwei Jahren noch trägt.
