Human-AI Teaming i de Firma

Vili Firmene started ihri AI-Reis uf ähnlichi Wiis. En Finanzanalyst lot en Chatbot e Zämmefassig vo de Variance mache. En Ychäufer lot en Entwurf für e Mail a de Lieferant schriibe. En Kundedienscht-Mitarbeiter lot en Vorschlag für e Antwort mache. Alli Entscheidige und Handlige bliibed bi de Mensche. AI isch nume es Tool, wo gwüssi Schritt schnäller macht. De Wert isch real, aber es isch immer no individuelli Produktivität.

Das Modell isch beschränkt. Es stigeret d Produktivität vom Einzelne, ohni d Arbeitsarchitektur z ändere. Aber wenn d Firma afoot, AI ernst z näh, denn ändert sich d Situation. De Agent wartet nüm nume uf ad hoc Befähl. Er fangt a, i sich widerholendi und strukturierti Workflows yzgriffe. De Agent überwacht Exception, sammlet Evidence us mehrere System, bereitet Entscheidigsentwürf vor, leitet Fäll wiiter, rüeft Tool uf, und füehrt sogar bestimmti Handlige innert festgleite Grenze us.

A däm Punkt ändert sich d Beziehig zwüsche Mönsch und AI grundlegend. Es isch nüm de Benutzer, wo es Tool bruucht, sondern de Mönsch schaffet zäme mit eme digitale Teammitgliid.

Die Veränderig tönt eifach, aber d Implikatione sind gross. Sobald de Agent Teil vom Betrieb wird, muess d Firma d Arbeitsteilig, d Entscheidigspünkt, d Verantwortig, de Betriebsrythmus, d Leistigskennzahle und s tägliche Arbeitserläbnis nöi gstalte. D Frag isch nüm "wie bruuche mer AI", sondern "wie schaffed Mönsch und Agent als eini betrieblichi Einheit zäme".

Vom Benutzer zum Teammitgliid

Stell der en Controller im Finanzteam vor. Jede Monet muess er d Exception im Abschlussprozess prüefe. D Date sind verteilt uf ERP, Spreadsheet und E-Mail. Er muess Evidence sammle, d Policy prüefe und en Kommentar vorbereite. Die Arbeit widerholt sich, bruucht Zyt und isch voller Übergäb.

Im alte Modell chönt de Controller d AI bitte, es Dokument zämezfasse oder e Antwort z sueche. Das hilft, aber es ändert de Workflow nöd. De Controller muess immer no alli System ufmache, d Date einzeln prüefe und alles manuell zämesetze.

Im agentische Undernähme verschiebt sich s Muster. De Agent wartet nüm nume uf Befähl, sondern übernimmt Teil vom Workflow. Im Finanzabschluss überwacht de Agent Exception, sammlet Evidence us mehrere System und bereitet en Entwurf vom Kommentar für de Controller vor. Im Ychauf klassifiziert de Agent d Intake-Request, prüeft Lieferant und Verträg und leitet de Fall uf de richtig Wäg. Im Kundedienscht list de Agent d Fallhistorie, prüeft d Entitlement, bereitet e Antwort vor und cha bi Low-Risk-Fäll erlaubti Handlige usfüehre. Im IT-Betrieb richeret de Agent Incident a, füehrt erscht Diagnostike us und eskaliert nume die Fäll, wo würkli en Ingenieur bruuche.

Do isch de Agent nüm e "schnälli Funktion" uf em Bildschirm. Er wird zum Mitglied vom Betriebsteam mit eme bestimmte Arbeitsberych.

Wiso die Verschiebig wichtig isch

Sobald de Agent zum Teammitgliid wird, chönd drei Sache nümme implizit blibe.

Erstens: D Interaktion muess gstaltet werde, nöd organisch laufe. Wenn de Mönsch nume ab und zue öppis vo de AI frogt, cha d Interaktionsgstaltig locker si. Aber wenn de Agent am Workflow teilnimmt, muess d Firma festlege, wänn de Agent elei schaffet, wänn er e Bestätigung bruucht, wänn er de Fall am Mönsch übergit und wie de Mönsch verstoot, was de Agent scho gmacht het. Ohni die Gstaltig wird d Übergäb es Chaos. S Team vo de Mensche weiss nöd, was es vertraue cha, was es no mue prüefe und wänn es sött ygriffe.

Zweitens: Vertraue muess uf de Betriebsebeni ufbaut werde, nöd uf de allgemeine Wahrnähmig. Im Tool-Modell cha de Benutzer d AI usprobiere und denn sälber entscheide, ob s Ergebnis nützlich isch. Im Teammitgliid-Modell muess Vertraue systematischer si. D Lüt müend wüsse, dass de Agent innere klare Gränze schaffet, Evidence bruucht, wo me cha gsee, d Policy iihaltet und dass me ne cha aahalte oder überstimme, wänn nötig.

Drittens: D Verantwortig muess mönschlich blibe, au wenn d Uusfüehrig immer digitaler wird. D Firma cha nöd säge, "de Agent het entschide". Bi Entscheidige, wo Uswirkige uf Kundä, Regulierigsbehörde, Mitarbeiter oder de Abschluss händ, blibt di externi Verantwortig bi de Mensche und de Institution. Drum muess d Gstaltig vom Human-AI Teaming immer d Froog beantworte: Wär isch verantwortlich für s Endresultat?

Wänn s Teammitgliid-Muster no nöd passt

Nöd alli Use Cases müend zu eme Human-Agent Team zwunge werde. Wenn d Arbeit no sehr sporadisch, sehr kreativ oder starch abhängig isch vo Verhandlige und eme fyne soziale Kontext, denn isch s normale Assistant-Modell oft besser. D Erarbeitig vo de Konzernstrategii, Verhandlige vo komplexe Verträg, d Bearbeitig vo emotionale Kunde-Eskalatione oder organisatorischi Entscheidige mit vilne politische und kulturelle Abwägige sind gueti Bischpiil. I dene Beriich isch AI immer no nützlich, aber sicherer als Berater statt als operative Teammitgliid.

Arbeitsteilig: Was de Agent macht, was bim Mönsch blibt

Es gsunds Human-AI Teaming entstaht nöd us de Annahm, dass de Agent "alles übernimmt, wo me cha automatisiere." Sonen Aasatz schiiteret meistens, wil er d Art vo de Arbeit im Undernähme ignoriert, wo voll isch vo Usnahme, Beurteilige und Verantwortige. Was bruucht wird, isch e expliziti Arbeitsteilig.

Arbeit, wo normalerwiis für de Agent passt

Praktisch gsee isch de Agent am stärchste bi Arbeit, wo Gschwindigkeit, Konsistenz und Uusdauer i grosse Mengene bruucht, vor allem wenn Entscheidige uf Regle, Evidence oder gnueg klari Muster chönd gstützt werde.

Monitoring isch eini vo de beste Kategorie. De Agent isch sehr effektiv bim Überwache vo betriebliche Signaal, wo ständig i Bewegig sind: Exception-Rächnige, verspäteti Lieferige, nöd bearbeiteti Kundetickets, Infrastruktur-Alerts oder Anomalie im Abschlussprozess. Mensche werded müed, wenn si ständig grossi Mengene müend überwache. De Agent nöd.

Retrieval und Evidence Assembly sind au starchi Beriich. Date us mehrere Quelle hole, Policy, Fallhistorie und unterstützendi Dokumänt zämeträge – das isch Arbeit, wo oft vil Zyt bruucht. De Agent cha die Phase massiv beschlünige. Im Finanzwese sammlet de Agent d Saldobilanz, die zughörige Journale, historischi Erklärige und die relevante Rechnigslegigspolicy, bevor de Controller d Exception prüeft.

Drafting isch en anderi Kategorie. Bi vilne Prozess chunt de gröschti Wert vom Entwurf: Entwürf für Kundeantworte, Kommentar zum Abschluss, Zämmefassige vo Vorfäll, Klassifikatione vo Ychaufsaafrage. En guete Entwurf reduziert d Aafangsziit, git aber em Mönsch immer no Ruum für s Beurteile.

Reconciliation, Routing und reglebasierti Uusfüehrig sind au guet für de Agent. De Agent cha Date us verschiedene Quelle abglyche, Abwichige finde und markiere. Er cha bestimme, i wele Kanal en Fall ghört, wär de richtigi Genehmiger isch oder wänn en Fall söll eskaliert werde. Bi bestimmte Use Cases cha de Agent Low-Risk-Handlige usfüehre, wo scho mit de Policy ygschränkt sind, zum Bischpil es Ticket ufmache, de Status aktualisiere, e Benachrichtigig schicke, en Entwurf für e Aafrag mache oder nidrigwertigi Handlige verarbeite, wo d Bedingige erfülle.

Arbeit, wo immer no besser bim Mönsch blibt

Umgekehrt gits Beriich, wo de Mönsch immer no überläge isch, nöd wil d Technik no nöd wit gnue isch, sondern wil d Art vo de Arbeit ebe mönschlichi Qualitäte und höcheri Verantwortig verlangt.

Mehrdütigs Beurteile isch ein devo. Wenn d Evidence nöd vollständig isch, Regle sich widerspräche oder de Gschäftskontext schnäll ändert, isch de Mönsch besser im Abwäge vo de Unsicherheit. Empathii isch au wichtig. Im Kundedienscht, HR oder bi Service-Recovery isch d Qualität vo de mönschliche Interaktion entscheidend. En verärgerte Kunde oder en Mitarbeiter mit eme sensible Thema will nöd s Gfühl ha, dass er im falsche Moment vo "ere Maschine behandlet" wird.

Verhandlige, strategischi Abwägige und externi Verantwortig bliibed au bim Mönsch. Verhandlige mit Lieferante, d Lösig vo Stritfäll oder Kompromiss zwüsche Abteilige bruuched immer no Mensche. Entscheidige, wo Gschäftsprioritäte, Reputationsrisiko oder d Zuteilig vo Ressource über Abteilige hinweg betreffed, sind nöd für de Agent geeignet. Bi Entscheidige, wo me vor eme Prüfer, de Regulierigsbehörde, grosse Kundä oder em Verwaltigsrot muess verantworte, blibt de Mönsch de Inhaber vom letzte Mandat.

Bruuch d Matrix mit vier Zone

En praktische Wäg, d Arbeitsteilig z gstalte, isch die vier Zone. Zone Assist: De Agent liferet Informatione, Zämmefassige, Entwürf; de Mönsch entscheidet und füehrt us. Zone Recommend: De Agent git e Empfählig uf Basis vo de Evidence; de Mönsch stimmt zue oder lehnt ab. Zone Execute with Approval: De Agent füehrt en Schritt us, nachdem er d Genehmigung übercho het; de Mönsch isch de Gate für bestimmti Handlige. Zone Execute with Monitoring: De Agent füehrt Low-Risk-Handlige innert de Policy-Gränze us; de Mönsch überwacht d Usnahme und d Resultat.

Die Matrix hilft de Firma, die beide Extreme z vermyde: z konservativ, so dass de Agent nume en tüüre Chatbot isch, oder z aggressiv, so dass de Agent Otonomii überchunt, bevor d Kontrolle und s Vertraue bereit sind.

Was nöd stillschwiigend automatisiert werde sött

Eine vo de gföhrlichste Fehler isch, de Agent i sensible Beriich lo z laufe, ohni dass me explizit entschide het. D Firma muess bewusst festlege, welli Handlige verbote sind, welli Entscheidige immer en Mönsch bruuched und welli Bedingige e Eskalation erzwinge. Im Finanzwese dörf d Behandlung vo materiale Positione nöd automatisch entschide werde. Im HR dörfed Entscheidige, wo de Aastelligsstatus oder d Entlöhnig betreffed, nöd ohni starchi Governance automatisiert werde. Im Kundedienscht sind Stritfäll, Betrugsverdacht oder Kunde mit höchster Priorität normalerwiis nöd für volli Automation geeignet. Im IT-Betrieb dörfed riskanti Produktionsänderige nöd vom Agent ohni scharfi Kontrolle usgfüehrt werde.

Vertraue und Adoption: Nöd eifach e Frog vo de Genauigkeit

Vili AI-Programm schitere i de Adoptionsphase, wil si z vil uf "höchi Genauigkeit" oder "fortschrittlichi Reasoning-Fähigkeite" setzed. Im echte Betrieb wird Vertraue nöd vo sonige Präsentatione ufbaut. Vertraue entstaht, wenn d Lüt s Gfühl händ, dass si verstönd, was de Agent macht, dass si d Interaktion chönd kontrolliere und dass s Arbeitserläbnis konstant hilft, statt z belaschte.

Die drei wichtigste Grundlage für Vertraue

Erstens: Transparenz. D Benutzer müend d Grundlag vo de Arbeit vom Agent gsee: welli Date bruucht worde sind, welli Policy referenziert worde isch, welli Tool ufgruefe worde sind und wiso e bestimmti Empfählig usecho isch. Das heisst nöd, dass alli interne Reasoning-Schritt offe müend gleit werde. Was bruucht wird, isch gnueg Evidence zum beurteile. Im Kundedienscht, wenn de Agent en Ruckzahlig vorschlaat, muess de Supervisor d Entitlement, d Fallhistorie und d Policy gsee, wo de Vorschlag stützt.

Zweitens: Kontrollierbarkeit. D Benutzer müend chöne korrigiere, Feedback gä, Empfählige ablehne oder de Fall übernäh. Wenn de Agent sich wie en Blackbox aafüehlt, wo de Workflow erzwingt, fallt s Vertraue schnäll.

Drittens: Konsistenz. En Agent, wo mal sehr hilfreich isch und mal d Arbeitsschritt komplizierter macht, wird schwierig z adopteere. S Erläbnis muess stabil gnue si, dass s Team weiss, wänn de Agent verlässlich isch und wänn me ufpassen muess.

Adoption stigt, wenn d Friktion sinkt

Das isch es Prinzip, wo oft ignoriert wird. D Lüt adopteered en Agent nöd, wil d Firma seit, dass das d Zuekunft isch. Si adopteered en, wenn de Agent würkli di reali Friktion reduziert: weniger Copy-Paste, weniger manuelli Datesuechi, weniger Wächsle zwüsche System, weniger sich widerholendi administrativi Arbeit.

Umgekehrt wird d Adoption sinke, wenn de Agent unnötigi Genehmigige dezue bringt, Entwürf produziert, wo me komplett nöi schriibe muess, Empfählige ohni Evidence git oder de Benutzer zwingt, alles vo Aafang a nöi z prüefe.

Im Finanzabschluss, wenn de Agent nume en Kommentarentwurf macht, wo me trotzdem vollständig muess prüefe, isch de Wert chli. Aber wenn de Agent au d Evidence sammlet, di wichtigste Variance markiert und d Datequelle zeigt, denn wird de Controller s Gfühl ha, dass sini Lascht würkli reduziert wird.

Im Kundedienscht, wenn de Agent e Kundeantwort vorbereitet, aber de Supervisor immer no füf System muess ufmache, zum d Grundlag vo de Entscheidig z prüefe, denn het de Agent s Problem no nöd glöst. Was bruucht wird, isch es vollständigers Arbeitspaket: Empfählig plus Evidence plus vorbereiteti Handlig.

Feedback-Loop muess real si, nöd symbolisch

Damit Vertraue wachst, dörf s Feedback vom Mönsch nöd bimene Daumä ufe oder abe ufhöre. S Feedback muess wider i d Knowledge Base, i d Policy-Schwellwärt, i goldeni Szenarie für d Evaluierig und i s Tuning vom Workflow yfliesse. Wenn d Benutzer s Gfühl händ, dass ihri Ygab nie s Verhalte vom Agent ändert, denn höred si uf, sich z kümmere. Am Schluss läbt de Agent no, aber s Vertraue isch tot.

Betriebsrythmus für Human-Agent Teams

Sobald Mönsch und Agent als eini betrieblichi Einheit schaffed, bruucht d Firma en klare Rythmus. Ohne dä Rythmus wird s Human-AI Teaming sich aafühle wie es Experiment, wo jede für sich macht.

Die drei Rythme, wo normalerwiis bruucht werde

Erstens: De täglichi Exception-Review. De Fokus isch uf em tägliche Betrieb: Fäll, wo de Agent nöd het chöne bearbeite, höchi Override-Rate, sich widerholendi Exception, blockierti Handlige und Fläschehälss bi de Genehmigig. Dä Rythmus isch vor allem i de Aafangsphase vom Skalieren wichtig. S Ziel isch nöd, alli Interaktione z prüefe, sondern sicherzstelle, dass s Team schnäll gseet, wo de Agent hilft und wo er nöii Belaschtige schafft.

Zweitens: De wöchentlichi Performance-Tuning. Uf de wöchentliche Ebeni muess s Team d Fallmengi, d Akzeptanzrate vo de Agent-Empfählige, d Eskalationsrate, d Korrekturrate, d Latenz und d Feedback-Muster vo de Benutzer prüefe. Do wärded d Tuning-Entscheidige troffe: Sind d Schwellwärt z konservativ? Muess de Retrieval verbesseret werde? Sönd d Prompt oder de Workflow vereifacht werde? Gits Falltype, wo me besser us em Scope use nimmt?

Drittens: De monatlichi Risiko- und Governance-Review. Monatlich verlageret sich de Fokus uf d Governance: Gits Policy-Verstöss? Gits en Drift i de Qualität? Gits Änderige bi de Regulierig oder de SOP? Isch de Grad vo de Otonomii no passend? Sött de Use Case erwiiteret oder zrugggno werde? Dä Rythmus isch wichtig, wil s Human-Agent Team nöd nume über Produktivität goot, sondern au über Kontrolle.

Bischpiil für en Operating Cadence: Finanzabschluss-Team

Da isch es eifachs Bischpiil für es Finanzteam, wo en Agent im Abschlussprozess bruucht. Täglich prüeft s Team d Liste vo de Exception, wo nöd automatisch glöst worde sind, lueget, welli Kommentar am hüfigste vom Controller überstimmt worde sind, und identifiziert d Entitäte oder Kontene, wo am meiste Eskalatione usglöst händ. Wöchentlich analysiert s Team d Akzeptanzrate vo de Kommentarentwürf, prüeft d Zytersparnis bim Evidence-Gathering, beurteilt, ob de Agent z vil nöd relevanti Dokumänt useholt, und aktualisiert d Evaluierigsszenarie mit de reale Fäll vo dere Wuche. Monatlich macht s Team en Review zäme mit de Controllership, em Risk und em Platform-Team, lueget, ob sich d Accounting-Policy gänderet het, wo i d Knowledge Base muess, beurteilt, ob de Scope vom Agent vo Draft uf Recommend i bestimmte Beriich cha erwiiteret werde, oder ob er abgstueft werde muess, wenn d Qualität no nöd stabil isch.

Bischpiil für en Operating Cadence: Kundedienscht

Täglich prüeft s Team d Fäll, wo nach de Bearbeitig mit Hilf vom Agent wider ufgmacht worde sind, lueget d Refund-Empfählige aa, wo de Supervisor abglehnt het, und identifiziert Muster bi Kundä oder Produkt, wo hüfig zu Fehler füehred. Wöchentlich misst s Team, ob d average handling time würkli gsunke isch, lueget, ob de Agent d Übergäb reduziert oder vermehrt het, und verbesseret d Knowledge-Artikel, wo am hüfigste bruucht aber au korrigiert werde. Monatlich prüeft s Team s Risiko vo Stritfäll, Fairness und Policy-Yhaltig, beurteilt, ob es Kundesegment git, wo nöd für witeri Automation geeignet isch, und entscheidet, ob de Agent meh Low-Risk-Handlige dörf usfüehre.

Organisatorischi Implikatione: Wär füehrt s Human-Agent Team?

Human-AI Teaming cha nöd nume vom Technologie-Team gstüürt werde. Es bruucht en abteiligsübergriffendi Verantwortig. De Business Owner isch verantwortlich für s Prozessresultat. De Team Lead oder Operations Manager isch verantwortlich für di täglichi Arbeitswiis vom Team us Mönsch und Agent. S Platform- oder AI-Team sorgt für di technischi Qualität, d Observability und d Evaluierig. De Risk-, Compliance- oder Control Owner stellt sicher, dass d Gränze vo de Otonomii gsund blibed. De HR- oder Talent Leader hilft, d Rolle, d Fähigkeite und d Leistigserwartige nöi z gstalte.

Das bedütet au, dass d Organisationsstruktur sich muess verschiebe. De Supervisor managt nüm nume Lüt, sondern au e Mischig us mönschliche und digitale Arbeitschräft. Er muess nöii Kennzahle läse, d Fehlermodus vom Agent verstoh und d Verhaltensänderig vom Team füehre.

Praktischi Checkliste

Da sind d Entscheidige und d Checkliste, wo me nach em Verstah vo däm Thema sött träffe.

Entscheidige, wo jetzt tröffe werde müend

Leg s Teaming-Modell für jede Use Case fest. Isch de Agent nume Assist, Recommend, Execute with Approval oder Execute with Monitoring? Setz d Arbeitsteilig explizit fest. Welli Arbeit macht de Agent, was wird vom Mönsch validiert und was dörf nöd automatisiert werde? Gstalt s Arbeitserläbnis so, dass es Vertraue ufbaut. Welli Evidence muess sichtbar si, wänn cha de Benutzer überstimme und wie chunt s Feedback i d Systemverbesserig? Mach en formelle Operating Cadence. Wär füehrt de täglichi Exception-Review, s wöchentliche Tuning und de monatlichi Risk-Review? Klär d organisatorischi Verantwortig. Wär isch de Owner vom Resultat, wär de Owner vom Agent und wär het d Befuegnis, de Grad vo de Otonomii z erhöhe oder z senke?

Churzi Readiness-Checkliste

De Use Case isch em Modus Assist, Recommend, Approval oder Execute zuegordnet. Es git e expliziti Liste vo Ufgabe, wo für de Agent geeignet sind, und sonigi, wo bim Mönsch blibed. Handlige, wo verbote sind oder immer e Eskalation bruuched, sind festgleit. D Benutzer chönd di wichtigscht Evidence gsee, wo de Agent bruucht. Es git e Mechanismus zum Überstimme, Feedback gä und Korrigiere, wo eifach z bruuche isch. S Feedback vom Mönsch flüsst i d Knowledge, d Policy oder d Evaluierig vom Agent. S Betriebsteam het en tägliche, wöchentliche und monatliche Review-Rythmus. D Metrike messed nöd nume d Produktivität, sondern au Override, Eskalation, Korrektur und Risikosignaal. De Supervisor oder Team Lead verstoot, wie me en Human-Agent Workflow managt, nöd nume es Team vo Mensche. De Business Owner, Technical Owner und Control Owner sind klar.

Alarmzeiche

Das Thema isch no nöd bereit zum Skalieren oder bruucht zuesätzlichi Governance, wenn de Agent als "Ersatz für Lüt" positioniert wird ohni klari Arbeitsteilig, d Benutzer d Grundlag vo de Agent-Empfählige nöd gseend, s Überstimme schwirig isch oder als Versage vom Benutzer gwertet wird, Feedback nie i d Systemverbesserig yflüsst, d Genehmigige meh werded aber d Friktion nöd weniger, de Supervisor nöd weiss, wie er d Agent-Metrike list, oder d Verantwortig bi Fehler unklar isch.

Reflektionsfroge für CIO, COO, CHRO und Transformation Leader

CIO: Sind eui Architektur und Observability scho gnue, dass d Arbeit vom Agent transparent und vom Betriebsteam kontrollierbar isch? COO: Gstaleted dir würkli de Workflow nöi, oder chlebed dir nume AI a alti Prozess aa? CHRO: Wärded d Rolle vom Supervisor, Analyst und Operator scho nöi definiert, zum digitali Teammitgliider z füehre? Transformation Leader: Reduziert de Agent i euere Firma di reali Friktion, oder bringt er under em Name vo de Governance nume nöii Arbeitsschicht dezue?

Am Schluss isch Human-AI Teaming nöd eifach d Sach, dass de Mönch "mit Hilf vo AI" es biz schnäller wird. Es isch d Nöigstaltig vo de betriebliche Einheit: Wär macht was, wär entscheidet was und wie schaffed Mönsch und Agent zäme besseri Resultat. Wenn die Gstaltig mit Disziplin gmacht wird, denn überchunt d Firma nöd nume Effizienz, sondern au es nöis, robuschters Arbeitsmodell, wo besser messbar und besser zum Skalieren isch.