Studij slučaja: kako sam uočio poslovni rizik Slacka u odnosu na e-mail za čuvanje kritičnih informacija
Ovaj studij slučaja nastao je iz vrlo konkretnog poslovnog pitanja: mogu li dugoročno i pod svojom kontrolom sačuvati kritične informacije koje mi šalje vanjski poslovni partner, ili postoji rizik da ih izgubim zbog pravila platforme koju koristim za komunikaciju.
Polazna točka
Nisam krenuo od opće usporedbe Slacka i e-maila, nego od točno definiranog poslovnog rizika. Zanimalo me što se događa kada mi vanjski poslovni partner pošalje vrlo važne tekstualne podatke, a ja te podatke moram moći dugoročno zadržati u svom poslovnom sustavu.
Moje pitanje nije bilo je li Slack moderan, brz ili praktičan. Moje pitanje bilo je je li u ovom konkretnom scenariju Slack pouzdaniji, jednako pouzdan ili lošiji od običnog e-maila kada se radi o trajnom čuvanju poslovno kritične informacije.
Parametri koje sam jasno postavio
Scenarij 1: e-mail
Postavio sam jednostavan i poslovno logičan primjer. Ako mi vanjski partner pošalje važan e-mail, a ja taj e-mail ne obrišem, nastavim koristiti isti mailbox i po potrebi napravim vlastiti backup, tada zadržavanje te poruke ostaje primarno pod mojom kontrolom.
Drugim riječima, ako pošiljatelj kasnije obriše svoj primjerak poruke, to samo po sebi ne znači da će nestati i moj primljeni primjerak. U e-mail modelu zadržavanje poruke ovisi o mom mailboxu, mojim retention pravilima i mom backupu, a ne o tome što je vanjski pošiljatelj kasnije napravio na svojoj strani.
Scenarij 2: Slack Connect
Zatim sam postavio drugi scenarij. Ja koristim Slack Pro, a moj vanjski poslovni partner koristi Slack Free. Pitanje je bilo vrlo precizno: mogu li kao Pro korisnik izgubiti važnu poruku koju je poslala vanjska strana, iako ja osobno nisam ništa obrisao i uredno plaćam svoj plan.
Na temelju službene Slack dokumentacije, odgovor je pokazao da u Slack Connect komunikaciji moje retention postavke vrijede samo za sadržaj koji šalju moji članovi, dok se sadržaj koji šalje vanjska organizacija zadržava ili briše prema pravilima njihove organizacije.
To je ključ cijelog slučaja.
Što je ovdje dokazano
Kod e-maila je primljena poruka, u normalnom poslovnom scenariju, primarno pod mojom kontrolom sve dok moj sustav, moja pravila zadržavanja i moj backup tu poruku čuvaju.
Kod Slack Connecta situacija je bitno drukčija. Ako vanjska strana pošalje poruku, dugoročno zadržavanje te poruke nije potpuno pod mojom kontrolom. Ono ovisi o pravilima vanjske organizacije. To znači da kao korisnik Slack Pro plana mogu izgubiti poruku koju nisam obrisao, samo zato što je vanjska strana podložna drugačijem retention modelu.
Najvažnija razlika: kod e-maila zadržavanje primljene poruke primarno je pod mojom kontrolom, dok kod Slack Connecta zadržavanje poruke koju šalje vanjska strana nije potpuno pod mojom kontrolom.
Zašto je to poslovni rizik
U poslovnom smislu ovo nije tehnička sitnica. Ako vanjska poruka sadrži povjerljivu informaciju, ključni dogovor, tehničku specifikaciju, važan projektni zaključak ili podatak velike financijske vrijednosti, tada pitanje tko kontrolira dugoročno zadržavanje te poruke postaje pitanje upravljanja rizikom.
U ovom scenariju Slack može biti lošiji od običnog e-maila za čuvanje kritičnih informacija koje dolaze od vanjskih partnera. Razlog nije to što je Slack nužno loš alat općenito, nego to što u ovom konkretnom modelu komunikacije ne kontroliram u potpunosti sudbinu poruka koje šalje vanjska organizacija.
Gdje je AI model pogriješio i zašto je to važno
U ovom razgovoru pojavio se još jedan važan sloj rizika: rizik da AI model korisniku pripiše tvrdnju koju korisnik zapravo nije napisao.
Ja sam jasno napisao da Slack, u ovom scenariju, može obrisati važne podatke nakon određenog vremena i time ih ukloniti i iz mog Pro okruženja, ovisno o retention pravilima vanjske strane. To je formulacija mogućnosti i poslovnog rizika.
Međutim, AI model je u jednom dijelu razgovora moju formulaciju pogrešno preoblikovao kao da tvrdim da se to događa nužno ili automatski u svakom slučaju. To nije bio podatak iz razgovora. To nije bila moja formulacija. To je bio dodatak koji model nije smio unijeti.
Ovo je važna pouka: AI model može promijeniti razinu tvrdnje — od „može” prema „nužno”, od rizika prema navodnoj sigurnoj činjenici. U poslovnom radu to nije mala greška, nego ozbiljan problem interpretacije.
Ako AI model u relativno kratkom i jasnom razgovoru korisniku pripiše jaču tvrdnju od one koju je korisnik stvarno napisao, tada postoji stvaran operativni rizik u korištenju AI-a za poslovne, tehničke, pravne i upravljačke zaključke.
Što mi je ovaj slučaj pokazao
Prvo, kod odabira poslovnih komunikacijskih alata nije dovoljno gledati samo brzinu komunikacije, integracije i organiziranost kanala. Treba provjeriti i tko stvarno kontrolira dugoročno zadržavanje poslovno važnih informacija.
Drugo, AI model može biti vrlo koristan za ubrzavanje analize, ali samo ako korisnik postavi precizne parametre i ako se svaka važna tvrdnja provjeri na izvoru.
U ovom slučaju upravo su jasno definirani parametri omogućili da se otkriju dva odvojena rizika:
- rizik proizvoda — Slack Connect može smanjiti moju kontrolu nad dugoročnim čuvanjem vanjski poslanih informacija
- rizik interpretacije — AI model može korisniku pripisati formulaciju koju korisnik nije napisao
Završni zaključak
Na temelju službene dokumentacije i provjerenih izvora koje sam pregledao, moj zaključak za ovaj konkretan scenarij je jasan:
Ako mi vanjski partner šalje poslovno kritične informacije koje moram dugoročno sačuvati pod svojom kontrolom, obični e-mail je u tom pogledu sigurniji model od Slack Connect komunikacije s vanjskim partnerom čiji plan i retention pravila ne kontroliram.
Slack u ovom scenariju može dovesti do gubitka vanjski poslanog sadržaja i u mom Pro okruženju, dok je kod e-maila zadržavanje primljenog sadržaja primarno na mojoj strani. Istodobno, ovaj razgovor pokazao mi je i da AI model ne smijem tretirati kao automatski nepogrešiv izvor, nego kao alat čije formulacije moram strogo provjeravati, osobito kada se radi o razlici između „može” i „nužno”.