Kako AI može pomoći s poslovnom e-poštom

Ukratko:

• Pravila usmjeravaju, AI predlaže (kategoriju, sažetak, nacrt), čovjek odobrava slanje.
• Počnite s jednim sandučićem, uskim skupom kategorija i nacrtom koji odgovorna osoba provjerava uz izvornu poruku.
• Čitanje, nacrt i slanje su različite ovlasti; poruke, poveznice i privici nepouzdani su ulazi.
• Pilot vodite 30 dana u sjeni, s metrikama s jasnim nazivnikom.

U ponedjeljak ujutro u zajedničkom inboxu podrške već stoji nit o nedostavljenoj pošiljci, upit za ponudu s tri privitka i obavijest dobavljača koja izgleda strojno generirana. Ako softver treba pomoći, ima smisla automatizirati zaprimanje, razvrstavanje, dohvat konteksta i pripremu nacrta. Slanje ostaje iza provjera i jasne ovlasti.

Pravila pokrivaju poznate kategorije, primatelje, rokove i dopuštene radnje. Model ima smisla kad je jezik promjenjiv: sažetak niti, prijedlog kategorije, nacrt odgovora. Čovjek odlučuje kad je namjera nejasna, kad u poruci ima osjetljivih podataka, kad se kupcu nešto obećava, kad postoji pravna ili financijska posljedica ili kad slučaj iskače iz pravila.

Ovo je operativna obrada dolazne pošte i zajedničkih sandučića: podrška, upiti s weba, zahtjevi dobavljača, interni zahtjevi i slični redovi. Marketinške kampanje, hladno kontaktiranje, newsletteri i isporučivost masovne pošte drugi su sustav.

Ako je cilj odgovarati zaposlenicima iz odobrenih internih uputa i po potrebi otvoriti IT tiket, pogledajte zaseban vodič za AI bot za IT podršku zaposlenicima.

Brzi odgovor: pravila usmjeravaju, AI predlaže, čovjek odobrava

Počnite s jednim sandučićem, uskim skupom kategorija i nacrtom koji odgovorna osoba može provjeriti uz izvornu poruku i korištene izvore. Ako su kategorija i sljedeća radnja potpuno predvidljive, dovoljan je običan radni tijek. Ako poruku treba protumačiti, model može vratiti strukturirani prijedlog. Ako je odluka osjetljiva ili teško povratna, slučaj preuzima čovjek.

Širi izbor između ovih pristupa opisuje vodič AI agent, chatbot ili automatizacija. Na zajedničkom sandučiću često je dovoljan običan tijek s jednim uskim AI korakom. Autonomni agent sa svim alatima tu rijetko treba.

Sedam koraka od nove poruke do kontroliranog odgovora

1. Primite događaj, zatim dohvatite stvarno stanje

Push obavijest samo kaže da se sandučić promijenio. Nije poslovna naredba i nije cijeli zapis.

Gmail API push obavijesti idu preko Cloud Pub/Suba. Nakon promjene stiže oznaka povijesti, a klijent dohvaća detalje od zadnjeg poznatog historyId. Dokumentacija sama kaže da obavijesti mogu kasniti ili izostati i zato preporučuje rezervnu sinkronizaciju. Gmailov watch ima rok valjanosti. Obnovu stavite u raspored, ne u nečije pamćenje.

Microsoft Graph change notifications mogu obavijest isporučiti webhookom (automatska poruka koju jedan sustav šalje drugome kad se nešto dogodi), Event Hubsom ili Event Gridom. Za sadržaj sandučića message delta vraća dodane, promijenjene ili izbrisane poruke u određenoj mapi. Nastavak i sljedeći krug sinkronizacije idu preko nextLink i deltaLink.

U oba slučaja pokazivač spremite tek kad je potrebni skup promjena stvarno obrađen. Povremeno usporedite lokalno stanje s pružateljem. Bilježite kašnjenja, praznine i istek pretplate. Događaj je onda ubrzanje. Istina i dalje stoji u sandučiću.

2. Učinite svaki korak sigurnim za ponavljanje

Push sustav ponavlja isporuku kad potvrda ne stigne. Mreža može prekinuti odgovor. Ista se nit može promijeniti više puta. Zato svakoj obradi dajte stabilan ključ: organizacija, sandučić, identifikator poruke ili promjene, verzija tijeka i namjeravana radnja. Prije oznake, tiketa, upisa u CRM (sustav za evidenciju odnosa s kupcima) ili slanja provjerite postoji li za taj ključ već uspješan rezultat.

Događaj nije gotov zato što je model vratio tekst. Gotov je kad je rezultat trajno spremljen, provjere su prošle i stanje povezane radnje je poznato. Ako API za slanje istekne nakon zahtjeva, prvo uskladite poslane poruke ili vlastiti zapis operacije. Nemojte slanje ponoviti naslijepo.

3. Razvrstajte poruku u tipiziranu shemu

Slobodan sažetak nije signal po kojem se može usmjeravati. Izlaz neka bude mala shema s dopuštenim vrijednostima, na primjer:

• category: jedna od dogovorenih kategorija ili unknown;
• queue: postojeći red rada ili human_review;
• priority_signal: opisani signal hitnosti, ne konačna poslovna odluka;
• requested_action: što pošiljatelj traži prema sadržaju poruke;
• language, thread_summary i identifikatori pronađenih entiteta;
• evidence: dijelovi poruke ili niti na kojima se prijedlog temelji;
• risk_flags: osjetljivi podaci, privitak, promjena računa, prigovor, prijetnja ili druga unaprijed definirana zastavica.

OpenAI function calling u strict načinu drži izlaz uz definiranu shemu: sva polja obvezna, bez dodatnih svojstava. Shema drži format. Ne dokazuje da je kategorija točna. Kod ponovno provjerava tipove i dopuštene vrijednosti, a evaluacijski skup mjeri što se događa na stvarnim varijantama.

Ocjena pouzdanosti modela nije ovlast za slanje i nije razlog da se preskoči poslovno pravilo.

4. Dohvatite samo odobreni kontekst

Nacrt treba stajati na izvorima koje organizacija može imenovati i održavati: aktualna politika, potvrđen zapis kupca, narudžba, ugovoreni rok, prethodna komunikacija, uputa vlasnika procesa. Uz svaki dohvaćeni podatak čuvajte izvor, identifikator i verziju. Osobi koja pregledava nacrt pokažite poveznicu na taj dokaz, ne samo sažetak koji je model sastavio.

Sadržaj poruke ne smije sam proširiti skup izvora. Poveznica u poruci nije odobrenje da agent otvori stranicu, preuzme datoteku ili pošalje podatke drugom servisu. Ako je vanjski dohvat stvarno potreban, radi ga zaseban ograničen alat: dopuštena domena, vrsta sadržaja, veličina i dopuštena namjena.

Za identitet, uske alate, zapis i oporavak pogledajte kako sigurno povezati AI agente s internim sustavima.

5. Pripremite nacrt, ne gotovu odluku

U nacrtu odvojite činjenice iz poruke, potvrđene podatke iz sustava i tekst koji model predlaže. Ako nedostaje broj narudžbe, ovlaštenje, prilog ili potvrđena politika, nacrt treba tražiti taj podatak ili predati slučaj. Prazninu ne treba popuniti pretpostavkom.

U prvom opsegu rezultat ide u red za pregled ili u mapu nacrta. Osoba treba vidjeti primatelje, predmet, cijelu nit, predloženi tekst, predložene privitke, pronađene izvore i upozorenja.

U poruci koja ide van ne obećavajte rok, povrat, popust, ugovornu promjenu ili drugu obvezu samo zato što tako obično zvuči. Takva tvrdnja treba potvrđen podatak i vlasnika odluke.

6. Provedite determinističke provjere prije odobrenja

Tekst koji je vratio model ponovno prolazi kroz pravila koja se mogu opisati kodom:

1. Primatelji: dopuštena domena ili poznata adresa, očekivani To, Cc i Bcc, bez neočekivanog širenja preko reply-all.
2. Nit: odgovor pripada pravoj niti, organizaciji i slučaju. Citirani sadržaj ne otkriva poruke iz drugog predmeta.
3. Privitci: svaki je namjerno odabran, pripada slučaju, dopuštene je vrste i pregledan prema sigurnosnom postupku organizacije.
4. Tvrdnje: imena, identifikatori, iznosi, datumi i statusi podudaraju se s potvrđenim izvorom.
5. Politika: obvezne napomene su tu, zabranjene tvrdnje nisu unesene, iznimka je označena.
6. Radnja: odabrana operacija dopuštena je tom identitetu i toj fazi pilota te ima stabilan idempotentni (isti zahtjev poslan više puta ne stvara duplikate) ključ.

NIST SP 800-177 Rev. 1 opisuje SPF, DKIM i DMARC kao provjeru domene pošiljatelja, a TLS kao zaštitu prijenosa. Ti signali ulaze u sigurnosnu provjeru. Sami ne dokazuju da je osoba ovlaštena tražiti poslovnu radnju, niti da je sadržaj istinit. Model ih ne smije zamijeniti dojmom da poruka zvuči uvjerljivo.

7. Predajte slučaj pravoj osobi i zabilježite odluku

Predaja nije oznaka „niska sigurnost”. Pravilo treba imenovati red, ulogu i razlog: nepoznata kategorija, nedovoljan izvor, osjetljivi podaci, zahtjev izvan politike, promjena primatelja, neuobičajen privitak ili radnja s ozbiljnom posljedicom. Osobi pokažite izvor, nacrt, upozorenja i povijest promjena, tako da odluku može provjeriti bez da iznova čita cijeli slučaj.

OpenAI sigurnosne preporuke traže adversarijalno testiranje i ljudski pregled prije nego se rezultat pusti u praksu, posebno kad je posljedica ozbiljna. Evaluacija agenata može gledati trag cijelog izvođenja, pozive modela i alata, zaštitna pravila i predaje, i na tome uhvatiti pogrešan alat, propuštenu predaju ili kršenje politike.

Bez obzira na platformu, poslovni zapis treba pokazati tko je što predložio, tko je provjerio, tko je odobrio i tko je poslao.

Čitanje, nacrt i slanje nisu ista ovlast

Gmail API opsezi preporučuju najuži pristup koji aplikaciji treba. Opseg gmail.compose upravlja nacrtima, ali također dopušta slanje. Granicu „samo nacrt” zato morate provesti u servisu. Naziv opsega tu granicu ne drži. Microsoft Graph razlikuje delegirane i aplikacijske ovlasti.

Pregled Graph ovlasti objašnjava da aplikacijska ovlast radi bez prijavljenog korisnika. Referenca Graph ovlasti zasebno navodi, primjerice, Mail.Read, Mail.Read.Shared, Mail.Send i Mail.Send.Shared, te mogućnost da administrator ograniči pristup određenim sandučićima.

Za pilot razdvojite identitete i sposobnosti:

Nema univerzalnog izbora između delegiranog i aplikacijskog pristupa. Ovisi o sandučiću, vlasništvu, načinu rada, pravilima organizacije i tome što pružatelj podržava. Identitet ne treba širi pristup samo zato što ga je lakše složiti u konzoli.

Poruka, poveznica i privitak nepouzdani su ulazi

U poruci može stajati „zanemari prethodne upute”. Može stajati i skriveni tekst u dokumentu, poveznica koja pokušava promijeniti zadatak ili zahtjev da se podatak pošalje trećoj strani. To nije uputa vašem sustavu. To je sadržaj koji obrađujete kao podatak.

OWASP Excessive Agency štetne radnje veže uz preširoku funkcionalnost, preširoke ovlasti ili preširoku autonomiju. Jedan od okidača je izravna i neizravna prompt injection (podmetanje uputa modelu kroz tekst koji obrađuje) manipulacija. Korak koji čita poruku zato ne treba u isto vrijeme imati slobodno slanje, administraciju sandučića, upis u CRM i pregledavanje vanjskih stranica.

Izlaz držite na tipiziranoj shemi, alate na dopuštenom popisu, a podatke na nužnom kontekstu. Sadržaj poruke ne smije dodati novi alat, promijeniti sistemsku politiku, odabrati tajnu ili sam odobriti radnju.

U testni skup stavite upute u tijelu, u citiranoj niti, u potpisu, u poveznici, u HTML-u i u privitku. Gledajte i pogrešno slanje i pogrešno zadržavanje legitimnog slučaja.

Metrike s točnim nazivnikom

Jedna ukupna „točnost AI-a” u isti prosjek trpa pogrešno usmjeravanje, loš nacrt i opasnu radnju. Svaku fazu mjerite prema potvrđenom referentnom ishodu. Prije rezultata zapišite što računate kao pogrešku.

• Routing precision = poruke ispravno dodijeljene određenom redu / sve poruke koje je automatizacija dodijelila tom redu.
• Routing recall = poruke ispravno dodijeljene određenom redu / sve poruke koje prema potvrđenoj oznaci pripadaju tom redu.
• Draft acceptance without edits = pregledani nacrti odobreni bez sadržajne izmjene / svi pregledani nacrti. Unaprijed odredite računaju li se promjena primatelja, predmeta ili potpisa kao izmjena.
• Human correction time = ukupne aktivne minute potrošene na sadržajne ispravke / pregledani nacrti koji su zahtijevali sadržajnu ispravku. Uz prosjek prikažite medijan i rep distribucije kako nekoliko složenih slučajeva ne bi ostalo skriveno.
• Unsafe auto-send rate = automatski poslane poruke koje su prekršile definiranu provjeru primatelja, privitka, tvrdnje ili politike / sve automatski poslane poruke. U shadow fazi nema stvarnog automatskog slanja; zasebno mjerite simulirane prijedloge koji bi prekršili provjeru, bez prikazivanja nazivnika nula kao uspjeha.
• Duplicate-action rate = duplicirane oznake, tiketi, CRM upisi ili slanja / svi pokušaji odgovarajuće radnje koja mijenja stanje.
• Cost per correctly completed case = trošak modela, platforme, infrastrukture, ljudskog pregleda i operativnog održavanja / slučajevi koje je referentni proces prihvatio kao ispravno završene bez naknadne korekcije.

Uz to pratite vrijeme do prvog ispravnog usmjeravanja, udio predaje čovjeku, propuštene obvezne predaje, izostale ili zakašnjele događaje, neuspjele obnove pretplate i slučajeve u kojima ishod slanja nije poznat. Rezultate režite po kategoriji, jeziku, pošiljatelju, privitku i verziji tijeka.

Prag ovisi o cijeni pogreške, o procesu i o tome možete li provjeru napraviti neovisno. Nema postotka koji svaku automatizaciju čini spremnom za slanje.

Za poslovni izračun uzmite stvarni volumen i stvarni trošak u kalkulatoru cijene i ROI-ja AI agenta. Procjena iz pilota nije zajamčena ušteda.

Ograničeni 30-dnevni shadow pilot

Shadow pilot znači rad u sjeni: sustav samo predlaže, a ništa ne upisuje niti šalje u stvarnim sustavima (read-only, samo čitanje).

Trideset dana ovdje nije rok za produkciju. To je prozor u kojem na jednom sandučiću skupite dovoljno dokaza da odlučite o sljedećoj, i dalje uskoj, fazi.

Ako su podaci, ovlasti, evaluacijski skup, obnova pretplate ili vlasništvo iznimki i dalje nejasni, pilot ostaje bez slanja. Za izbor opsega može pomoći procjena procesa za AI automatizaciju.

Privatnost, čuvanje i pravni pregled

U porukama znaju stajati osobni podaci, poslovne tajne, ugovori, identifikatori i podaci osoba koje nisu izravni korisnici sustava. Kad se obrađuju osobni podaci, GDPR među načelima navodi zakonitost, ograničenje svrhe, smanjenje količine podataka, točnost, ograničenje pohrane, cjelovitost i povjerljivost te odgovornost voditelja obrade.

Zapišite:

• svrhu i pravnu osnovu;
• koji dio poruke i privitka prima koji servis ili model;
• gdje se obrađuje;
• tko su podizvršitelji;
• koliko se čuva;
• kako se briše;
• tko vidi zapise;
• što radite kad se dogodi incident. Tehnički zapis ne mora čuvati cijelo tijelo poruke ako je za dokaz dovoljan identifikator, sažetak provjere ili kontrolirani odlomak.

Konkretne obveze, rokove čuvanja i potrebu za procjenom učinka utvrdite s ljudima koji kod vas vode pravo, sigurnost i privatnost. Ovaj vodič nije pravni savjet.

Česta pitanja

Može li AI automatski odgovarati na emailove?

Tehnički može pripremiti i poslati poruku ako mu date tu ovlast. Sigurniji početak je razvrstavanje i nacrt, uz čovjeka koji pregleda. Automatsko slanje dolazi u obzir tek za vrlo uske kategorije, nakon dokaza, determinističkih provjera, jasnog vlasnika i oporavka koji stvarno radi. Nejasne, osjetljive i obvezujuće poruke ostaju iza odobrenja.

Treba li koristiti Gmail API ili Microsoft Graph?

Onaj API u kojem sandučić stvarno živi i koji pokriva događaje, dohvat, nacrte, ovlasti i zapise koje trebate. Izbor nije samo tehnički. Ovisi o identitetu, pravilima tenanta (zasebno korisničko okruženje organizacije u oblaku), zajedničkom sandučiću, potrebnim ovlastima i tome tko to operativno vodi. Ne spajajte oba ako proces koristi samo jedno.

Je li push dovoljan da nijedna poruka ne bude propuštena?

Ne računajte na njega kao na jedinu kopiju stanja. Gmailova dokumentacija izričito kaže da obavijest može kasniti ili izostati i zato preporučuje rezervnu sinkronizaciju. U svakom sustavu čuvajte pokazivač promjena, povremeno uskladite stanje i pratite istek pretplate, kašnjenje i pogreške obrade.

Kako spriječiti dvostruko slanje?

Svakoj namjeravanoj radnji dodijelite stabilan idempotentni ključ. Prije slanja provjerite prethodni rezultat i zapišite identifikator koji vrati pružatelj. Ako ishod zahtjeva nije poznat, prvo uskladite stanje, pa tek onda ponovite. Brojač pokušaja ne dokazuje da poruka već nije otišla.

Smije li AI otvoriti poveznicu ili privitak iz poruke?

Ne samo zato što se nalazi u poruci. Vanjski sadržaj može biti zlonamjeran, povjerljiv ili izvan svrhe koju ste odobrili. Ako dohvat treba, zaseban alat provjerava dopuštenu domenu, vrstu i veličinu, skeniranje, kamo podaci idu i tko smije. Model dobiva samo nužan rezultat.

Kako odabrati kategorije za prvi pilot?

Uzmite mali broj kategorija koje imaju vlasnika, dovoljno označenih primjera i sljedeći korak koji se može provjeriti. Obvezno zadržite unknown ili predaju čovjeku. Kategorije koje se preklapaju, ili koje traže pravnu i financijsku odluku, nisu dobar prvi kandidat za automatsko slanje.

Kada automatizacija e-pošte postaje AI agent?

Ako sustav prima događaj, pozove klasifikaciju, dohvati unaprijed određene izvore i spremi nacrt, to može ostati običan radni tijek s jednim AI korakom. Agent ima smisla tek kad mora birati među više dopuštenih alata i koraka, i kad ta složenost donosi nešto što možete izmjeriti. Naziv proizvoda ne dokazuje da vam agent treba.

Trebate pomoć s prvim pilotom?

Ako želite ovo primijeniti na svom procesu, javite se Sororu. Zajedno možemo odabrati jedan proces, zapisati granice ovlasti i dogovoriti kako ćete izmjeriti pilot. Pogledajte procjenu procesa za AI automatizaciju ili nam pišite na ante.barisic@gmail.com.

Službeni izvori

• Google for Developers — Configure push notifications in Gmail API
• Google for Developers — Choose Gmail API scopes
• Microsoft Learn — message: delta
• Microsoft Learn — Microsoft Graph API change notifications
• Microsoft Learn — Microsoft Graph permissions reference
• Microsoft Learn — Overview of Microsoft Graph permissions
• NIST — SP 800-177 Rev. 1, Trustworthy Email
• OpenAI — Safety best practices
• OpenAI — Function calling
• OpenAI — Evaluate agent workflows
• OWASP — LLM06:2025 Excessive Agency
• EUR-Lex — Uredba (EU) 2016/679, GDPR

Pregledano 31. kolovoza 2026. API-ji, ovlasti, ograničenja događaja, sigurnosne preporuke i pravne obveze mijenjaju se. Prije produkcijske, sigurnosne ili pravne odluke provjerite aktualne službene izvore i zahtjeve vlastite organizacije.