MI aģenti · jūsu sistēmā · dati paliek pie jums
MI aģenti strādājūsu sistēmā.Patstāvīgi un kopā ar jūsu komandu.
Katrs aģents strādā tikai savā darba iecirknī. Atmaksu aģents nevar mainīt cenas, un atbalsta aģents nevar grozīt līgumus ar partneriem. Aģenti izpilda procesus fonā — pēc grafika vai reaģējot uz notikumiem. Kad kādam komandā vajadzīga atbilde, aģents atrod un apkopo datus. Darbinieki var veltīt laiku lēmumiem, nevis meklēšanai pa sistēmas ekrāniem.
Aģentus ieviešam pakāpeniski, izmantojot platformu, kurai var uzticēt darbu ar jūsu uzņēmuma pamatsistēmu.
Tikai savā darba iecirknī
Aģents saņem piekļuvi konkrētām darbībām un datiem. Viss pārējais tam nav pieejams.
Ieviešana ar uzraudzību
Kamēr MI nav pierādījis savu lēmumu pareizību jūsu procesā, cilvēks pārskata katru lēmumu pirms izpildes. Kļūdainu lēmumu sistēmā neizpilda.
Garantijas nodrošina platforma
Katru izmaiņu pārbauda pirms nosūtīšanas un reģistrē žurnālā kopā ar iepriekšējām vērtībām, lai kļūdainu labojumu varētu atsaukt.
Ko dara aģenti
Strādā fonā un sniedz atbildes, kad vajag ātri tikt skaidrībā.
Divi darba režīmi vienā platformā ar vienādām garantijām. Aģenti izpilda procesus pēc grafika un reaģējot uz notikumiem. Ikviens komandā var arī palūgt aģentam atrast un apkopot datus no sistēmas, e-pastiem un klientu pieprasījumiem. Filtru, sarakstu un divpadsmit ekrānu vietā darbinieks saņem atbildi, uz kuras pamata var pieņemt lēmumu, un turpina izmantot ierastos rīkus.
Fonā
Aģenti izpilda procesus paši
Ienākošie dokumenti
Pretenzijas, sūdzības un atmaksas pieprasījumi, kas pienāk e-pastā. Aģents izlasa vēstules un pielikumus, atjaunina ierakstus un lūdz sūtītājam atsūtīt trūkstošos dokumentus.
Klientu pieprasījumi
Uz ierastiem jautājumiem aģents atbild, izmantojot jūsu zināšanu bāzi un atbilžu veidnes. Otrs modelis neatkarīgi novērtē katru atbildi.
Darbs ar partneriem
Piegādātāji, darbuzņēmēji un starpnieki. Aģents atjaunina noteikumus, cenrāžus, pieejamības datus un kontaktinformāciju pēc viņu e-pastiem un paziņojumiem. Katru izmaiņu reģistrē žurnālā.
Pēc pieprasījuma
Aģents atrod, cilvēks izlemj
Meklēšanu uzticiet aģentam
„Kuri partneri šajā valstī pagājušajā mēnesī mainīja noteikumus?“ Aģents pārskata sarakstus un ierakstus un sagatavo atbildi. Pusstundas darba ar filtriem vietā vajadzīga minūte, un darbinieks var pievērsties secinājumiem.
Visa lieta vienā atbildē
Pasūtījums, klienta pieprasījums, e-pasta sarakste ar partneri un iestatījumi, kas tos ietekmējuši — vienā atbildē ar saitēm uz ierakstiem jūsu sistēmā.
No atrastā līdz labojumam
Balstoties uz atrasto, aģents var uzreiz sagatavot izmaiņu scenāriju. Tas ietver tikai aģenta darba iecirknī atļautās darbības. Platforma scenāriju pārbauda un izpilda.
Aģenta darba iecirknis
Katrs aģents strādā tikai savā darba iecirknī.
Aģents, kas veic viena veida uzdevumus, nevar mainīt cita veida uzdevumu datus. Tā darba iecirkni nosaka pielaide — atļauto darbību un datu veidu saraksts. Atsevišķs API aģentiem nav vajadzīgs. Aģents izmanto to pašu API, ko jūsu sistēmas ekrāni.
Dati ārpus darba iecirkņa nav pieejami.
Izmaiņu scenāriju, kas skar datus ārpus pielaides, nevar palaist. Pielaidi pārbauda tajā pašā solī, kurā sāk izpildi, tāpēc starplaikā neviens to nevar mainīt.
Savs konts, ja to vēlaties.
Aģentam var izveidot savu lietotāja kontu jūsu sistēmā, tāpat kā jaunam darbiniekam. Tad arī jūsu sistēma pārbauda tā tiesības un savā žurnālā norāda aģentu kā darbību veicēju.
Redzat, kurš ko izdarījis.
Platformas žurnālā redzams, kurš un kad piešķīris aģentam pielaidi un kādus scenārijus aģents ar to izpildījis.
Pielaidi var atsaukt uzreiz.
Pielaidi maina vai atsauc ar vienu pogu. Nākamajā izpildes reizē jau piemēro jaunos noteikumus. Atsauktu pielaidi atjaunot nevar.
| Aģents | Atmaksas pieprasījumi | Klientu pieprasījumi | Partneru noteikumi | Cenas | Maksājumi |
|---|---|---|---|---|---|
| Atmaksu aģents | Atļauts | tikai atbildes | Nav piekļuves | Nav piekļuves | Nav piekļuves |
| Atbalsta aģents | Nav piekļuves | Atļauts | Nav piekļuves | Nav piekļuves | Nav piekļuves |
| Partneru aģents | Nav piekļuves | Nav piekļuves | Atļauts | tikai atlaides | Nav piekļuves |
Pielaižu tabulas piemērs. To sagatavojat kopā ar katra procesa atbildīgajiem. Izmaiņām nav vajadzīga programmēšana.
Kāpēc pilotprojekti apstājas
Pilotprojektus aizkavē viss, kas jāizveido ap modeli.
Modelis ar darbu tiek galā pietiekami labi. Kamēr aģents tikai lasa un iesaka, viss darbojas. Taču, tiklīdz tam patstāvīgi jāmaina dati jūsu uzņēmuma sistēmā, rodas jautājumi, uz kuriem demonstrācija neatbild.
Ko aģents drīkst darīt?
Piekļuve API parasti nozīmē piekļuvi visam API, bet kopīgs servisa konts redz visus datus uzreiz.
Kurš atbild par izmaiņu?
Ja visi aģenti izmanto vienu kontu, jūsu sistēmas žurnālā nevar noteikt, kurš ko mainījis.
Kas notiek, ja pusceļā pazūd savienojums?
Puse izmaiņu ir veikta, puse nav, un atkārtota izpilde rada dublikātus.
Kā izlabot kļūdu?
Ja neviens nav saglabājis iepriekšējās vērtības, tās nevar atjaunot.
Kur nonāk dati?
Klientu personas dati ārēja MI pakalpojuma sarakstes logā — tas ir jautājums jūsu juristiem.
Kā nepieļaut kļūdainus MI lēmumus?
Kamēr aģents nav pārbaudīts reālos gadījumos, tam nevar uzticēt jūsu darba sistēmu. Taču bezgalīgi apstiprināt katru soli izmaksā pārāk dārgi.
Kā tas darbojas
Katru no šiem riskiem novēršam kodā un datubāzē.
Šie risinājumi ļauj aģentiem strādāt sistēmā, ko uzņēmums lieto ikdienā. Tie darbojas neatkarīgi no cilvēku solījumiem būt piesardzīgiem.
Aģents izdara to, ko nedrīkst
Operāciju katalogs brīvas API piekļuves vietā.
Aģents izvēlas darbību no iepriekš aprakstīta saraksta un aizpilda parametrus. Darbību, kuras katalogā nav, aģents nevar veikt.
Katrai operācijai ir noteikti lauki, atļautās vērtības un noteikumi. Nezināmu operāciju nevar ne pārbaudīt, ne atsaukt, tāpēc katalogā to neiekļaujam.
Aģents iziet ārpus sava darba iecirkņa
Pielaide darbībām un datiem.
Katram aģentam ir savs atļauto darbību saraksts. Viena veida uzdevumu aģents nevar mainīt cita veida uzdevumu datus.
Platforma pārbauda pielaidi izpildes brīdī. Ja aģentam ir savs konts, arī jūsu sistēma pārbauda tā tiesības.
Kļūda, ko atklātu tikai sistēma
Pārbaude pirms nosūtīšanas.
Izmaiņu scenāriju pārbauda jau sagatavošanas laikā: formātus, klasifikatorus, saites uz esošiem ierakstiem, dublikātus un noteikumus par lauku savstarpējo atbilstību. Izmaiņu, kas neko nemainītu, nemaz neveido.
Atteikums masveida izmaiņu vidū izmaksā vairāk nekā papildu datu nolasīšana sagatavošanas laikā.
Kļūme masveida izmaiņu vidū
Izpilde turpinās arī pēc kļūmes.
Scenāriju ar simtiem operāciju var pārtraukt servera restartēšana, jūsu sistēmas atjauninājums vai savienojuma zudums. Pēc tam izpilde turpinās no tās pašas vietas.
Katru soli saglabā kopā ar tā žurnāla ierakstu. Soli, kura iznākums nav skaidrs, pirms atkārtošanas pārbauda jūsu sistēmā.
Atkārtota izpilde rada dublikātus
Neko neieraksta divreiz.
Ja sistēma neatbild, platforma vispirms vēlreiz nolasa datus un atkārto tikai to, kas nav nonācis sistēmā. Ja nav zināms, vai e-pasts klientam ir nosūtīts, to nesūta atkārtoti. Pārbaudi uztic cilvēkam.
Izveidei, maiņai un dzēšanai ir atšķirīgi noteikumi. Ja atbilde nav skaidra, soļa izpildi aptur, nevis min iznākumu.
Kļūdu vairs nevar izlabot
Žurnāls un labojumu atsaukšana.
Par katru soli platforma saglabā pieprasījumu, sistēmas atbildi un iepriekšējās vērtības, lai kļūdainu labojumu varētu atsaukt. Atsaukšanai no žurnāla izveido jaunu izmaiņu scenāriju un veic tās pašas pārbaudes. Pasūtījuma atcelšanu pie partnera vai klientam nosūtītu e-pastu atsaukt nevar. Šādām darbībām ir paredzēts lēmumu pārskatīšanas posms.
Žurnālā redzams, kāda darbība mainījusi konkrēto ierakstu, kurš aģents to veicis un kurā izpildes reizē.
MI pieņem kļūdainu lēmumu
Ieviešanas laikā — pārskatīšana pirms izpildes.
Kamēr process nav pierādījis savu uzticamību, cilvēks redz katru aģenta lēmumu formātā „bija → būs“ un var noraidīt visu scenāriju. Neatgriezeniskas darbības, piemēram, pasūtījuma atcelšanu pie partnera, apstiprina katram ierakstam atsevišķi.
Izpilda tieši pārskatīto versiju. Ja aģents to ir mainījis vai sistēmā ir mainījies ieraksts, pārskatīšanu sāk no jauna.
MI pārliecinoši raksta klientam aplamības
Otrs modelis pārbauda pirmo.
Cits modelis novērtē atbildes klientiem pēc noteiktiem kritērijiem, norāda savu pārliecības līmeni un izceļ vietas, kuras vērts pārlasīt.
Aģents nekad nevērtē pats sevi. Vērtējumus uzkrāj katram procesam, un tie ir viens no pamatiem, lemjot, vai aģentam ļaut strādāt patstāvīgi.
Uzbrucēja e-pasts vada aģenta rīcību
E-pasts ir dati, nevis norādījumi.
Aģents lasa pievienotās pastkastes, taču neko no e-pasta satura neuztver kā komandu. Aizdomīgas darbības, piemēram, klasifikatoru masveida eksportu, aģents atzīmē auditam.
Reģistrē katru aģenta izsaukumu un katru pieprasījumu sistēmai. Par atzīmētajām darbībām informē atbildīgos.
Ieviešana
Vispirms MI pierāda sevi, tad strādā patstāvīgi.
Ieviešot MI, lielākais risks ir kļūdainu lēmumu virkne — lielāks par jebkuru tehnisku kļūmi. Tāpēc jaunu procesu sākam ar pārskatīšanu: cilvēks redz katru lēmumu pirms izpildes, un kļūdainos sistēmā neizpilda. Pārskatīšana ir ieviešanas posms. Tas beidzas, kad aģenta lēmumiem vairs nav vajadzīgi labojumi. No tā brīža aģents strādā patstāvīgi.
- 1. posms
Meklēšana un analīze
Aģents atrod un apkopo komandai datus no sistēmas, e-pastiem un klientu pieprasījumiem. Pats tas neko nemaina. Noder jau pirmajā dienā, bez riska.
- 2. posms
Lēmumu pārskatīšana
Aģents sagatavo izmaiņas. Cilvēks redz „bija → būs“ un palaiž scenāriju vai to noraida. Sistēmā izpilda tikai pārbaudītus lēmumus.
- 3. posms
Patstāvīgi savā darba iecirknī
Ja praksē ir apstiprinājusies aģenta lēmumu pareizība, tas pats izpilda procesu savas pielaides robežās. Pielaidi var atsaukt ar vienu pogu.
- Mērķis
Aģenti strādā fonā, komanda — kopā ar tiem
Procesus, kuru uzticamība ir pierādīta praksē, sāk palaist automātiski. Aģenti tos izpilda pēc grafika vai reaģējot uz notikumiem, katrs savā darba iecirknī. Darbinieki ar aģenta palīdzību izprot datus un sāk jaunus darbus. Jaunus procesus joprojām sāk ar pārskatīšanu.
Žurnāls, izmaiņu atsaukšana, pārbaudes pirms nosūtīšanas un audits visos posmos ir vienādi. Mainās tas, kurš sāk izpildi un kādās robežās.
Piemērs · Eiropas auto nomas piedāvājumu portāls
Aģentu platforma operatīvā darba komandai
Mūsu klients, auto nomas piedāvājumu portāls, strādā ar apjomīgu pašu izstrādātu sistēmu: partneri un viņu noteikumi un cenrāži, pārdošanas noteikumi, atmaksas, pretenzijas un klientu pieprasījumi. Operatīvā darba komanda stundām veica vienādus labojumus desmitiem ekrānu un šķiroja e-pastus.
Mērķis ir aģenti, kas paši izpilda operatīvos procesus, un iespēja komandai ar aģenta palīdzību ātri piekļūt sistēmas datiem. Tam izveidojām MCP platformu, caur kuru aģenti strādā ar sistēmu. Tās tīmekļa portāls ļauj ieviešanas laikā pārskatīt katru aģenta piedāvāto izmaiņu, pārvaldīt piekļuvi un integrāciju iestatījumus, kā arī skatīt analītiku. Aģents atrod un apkopo datus no sistēmas, e-pastiem un klientu pieprasījumiem, tāpēc tie vairs nav jāmeklē pa ekrāniem. Ja vajadzīgas izmaiņas, aģents sagatavo scenāriju, un platforma to pārbauda un izpilda aģenta pielaides robežās.
Ar ko strādā aģenti
- Partneru noteikumi un cenrāži
- Atlaides un pārdošanas limiti
- Katalogs un klasifikatoru dati
- Atmaksas
- Pretenzijas
- Klientu pieprasījumi
- E-pasti klientiem
- Darbības ar pasūtījumiem
- Teksti un tulkojumi
- ≈90uzņēmuma sistēmas ekrāni, kuriem aģenti piekļūst caur vienu operāciju katalogu
- ≈50aģenta rīki: uzņēmuma sistēma, klientu pieprasījumi, e-pasts, dokumenti, prasmes
- 2 mēnešino pirmajām koda izmaiņām līdz platformas ikdienas lietošanai komandā; šajā laikā — 219 laidieni
- Simtiemoperāciju vienā izpildes reizē, ar izpildes turpināšanu pēc kļūmes
Pašlaik komanda strādā ar aģenta palīdzību un pārskata katru lēmumu pirms izpildes. Nākamais posms ir aģentu darbs fonā pēc grafika.
Viena izmaiņa no sākuma līdz beigām
- 01 · Aģents
Lasa
Sistēmas ierakstus, e-pastus, klientu pieprasījumus, pielikumus. Katru izsaukumu reģistrē audita žurnālā.
- 02 · Aģents
Sagatavo izmaiņu scenāriju
Tikai operācijas no kataloga un tikai savas pielaides robežās.
- 03 · Platforma
Pārbauda
Pirms nosūtīšanas atklāj visu, ko sistēma noraidītu: formātus, klasifikatorus, dublikātus, saites.
- 04 · Cilvēks ieviešanas laikā
Pārskata
„Bija → būs“ saprotamā valodā. Kļūdainu lēmumu noraida pirms izpildes.
- 05 · Platforma
Izpilda
Soli pa solim, žurnālā saglabājot vērtības pirms katras izmaiņas.
Atšķirība
Ar ko tas atšķiras no tērzēšanas bota pieslēgšanas API.
Kā tas darbojas
Tērzēšanas bots atbild, balstoties uz dokumentāciju
Aģenti izpilda procesus fonā un atrod aktuālos sistēmas datus, lai komanda varētu pieņemt lēmumus
Ko aģents drīkst darīt
Viss API ar kopīgu servisa kontu
Tikai savs darba iecirknis: pielaide konkrētām darbībām un datiem, vajadzības gadījumā arī savs konts
Cilvēka loma
Piedalās katrā solī bezgalīgi vai nepiedalās nemaz
Katru lēmumu pārskata, līdz MI pierāda sevi konkrētajā procesā, pēc tam process norit patstāvīgi
Kļūme operācijas vidū
Cilvēks manuāli noskaidro, kuras izmaiņas veiktas
Izpilde turpinās no pārtraukuma vietas, un soli ar neskaidru iznākumu pārbauda sistēmā
Kļūda
Atrod žurnālos un izlabo manuāli
Iepriekšējās vērtības glabājas žurnālā, un labojumu atsauc ar jaunu scenāriju
Atbildes klientiem
Modelis pārbauda pats sevi, vai nepārbauda neviens
Neatkarīgu vērtējumu sniedz otrs modelis
Audits
Modeļa žurnāli, ja tādi ir
Katrs aģenta izsaukums, katrs pieprasījums sistēmai, kurš aģents ko izpildījis un ar kādu pielaidi
Zināšanas par procesu
Viena cilvēka uzvednē
Prasmju aprakstos ar versijām un variantiem, kurus kopīgi izmanto komanda un aģenti
Dati un VDAR
Sensitīvie dati paliek jūsu infrastruktūrā.
Platformu izvietojam jūsu infrastruktūrā: Kubernetes, Azure, AWS vai jūsu serveros. Izpildes dati, žurnāli un audita dati glabājas pie jums, nevis ārēja MI pakalpojuma sarakstes logā. Piekļuvi nosaka jūsu noteikumi.
- Modeli izvēlamies atbilstoši uzdevumam un jurisdikcijai. Aprakstītajā projektā aģenta lomu pilda Claude, bet neatkarīgo pārbaudi veic cits modelis. Modeli var mainīt, nepārbūvējot platformu.
- Jūsu uzņēmuma sistēmai var piekļūt tikai viens serviss. Tās adrese un atslēgas nekad nenonāk pie aģenta vai pārlūkprogrammā.
- Portāls ir pieejams tikai no jūsu iekšējā tīkla. Pieteikšanās notiek ar uzņēmuma sistēmas kontiem, un atļauti ir tikai uzņēmuma domēni.
- Programmatūras atkarības instalē ne agrāk kā nedēļu pēc versijas publicēšanas — tas pasargā no kompromitētām pakotnēm.
- Dokumentējam piekļuves tiesības un katra datu veida glabāšanas termiņu. Vajadzības gadījumā sagatavojam tehnisko daļu novērtējumam par ietekmi uz datu aizsardzību.
Izmantojat modeli Azure vidē? Uzvedņu un atbilžu apstrādes vietu vairāk nosaka izvietojuma veids nekā resursa reģions. Azure izvietojuma veidi un VDAR
Ar ko sākt
Viens process ar mērījumiem pirms un pēc. Patstāvīgs darbs, kad uzticamība ir pierādīta praksē.
- 01
Izvēlamies procesu
Kopā ar cilvēkiem, kas veic šo darbu, saskaitām patērētās stundas un nosakām topošā aģenta darba iecirkni — vajadzīgās darbības un datus.
1 nedēļa
- 02
Meklēšana un analīze ar aģentu
Pievienojam sistēmu, e-pastu un klientu pieprasījumus. Komanda uzreiz sāk lūgt aģentam atrast un apkopot datus, un mēs redzam reālos jautājumus.
1–2 nedēļas
- 03
MI lēmumu pārskatīšana
Izveidojam procesa operāciju katalogu, pārbaudes, žurnālu un izmaiņu atsaukšanu. Cilvēks redz katru aģenta lēmumu pirms izpildes un noraida kļūdainos, pirms tie nonāk sistēmā.
3–4 nedēļas
- 04
Patstāvīgs darbs
Salīdzinām patērētās stundas, kļūdas un atbildes laiku, saskaitām aģenta lēmumus, kuriem nebija vajadzīgi labojumi. Kad process ir pierādījis uzticamību, to sāk palaist automātiski un izpilda aģents. Ja tas neatmaksājas, mēs to pasakām.
Tālāk pa vienam procesam
Jautājumi
Ko mums parasti jautā
Vai aģentiem jāizveido atsevišķs API?
Nē. Aģents izmanto to pašu API, ko jūsu sistēmas ekrāni. Ja vajadzīgs, tam izveido savu kontu, tāpat kā darbiniekam, un jūsu sistēma pārbauda tā tiesības. Ja API trūkst procesam vajadzīgu iespēju, norādām trūkstošās metodes un varam tās izstrādāt.
Kā nodrošināt, ka aģents paliek savā darba iecirknī?
Platforma katram aģentam piešķir pielaidi — darbību un datu veidu sarakstu. Viena veida uzdevumu aģents nevar mainīt cita veida uzdevumu datus, jo šādu scenāriju nevar palaist. Pielaidi pārbauda gan izmaiņu sagatavošanas laikā, gan sākot izpildi. Ja aģentam ir savs konts, arī jūsu sistēma pārbauda tā tiesības.
Ko fonā strādājošs aģents dara, ja nevar izlemt?
Tas apstājas un nodod lietu cilvēkam kopā ar jau savāktajiem datiem. Tāpat rīkojas, ja operācijas iznākums nav zināms: ja sistēma nav apstiprinājusi e-pasta nosūtīšanu klientam, to nesūta atkārtoti, bet nodod cilvēkam pārbaudīt. Ja kļūdaini veiktu darbību nevar atsaukt, platforma nepaļaujas uz minējumiem.
Kāpēc neļaut aģentam uzreiz darīt visu?
Iepriekš nav zināms, cik labi MI pieņems lēmumus tieši jūsu procesā. Pārskatīšanas posms novērš šo risku: cilvēks redz katru lēmumu un kļūdaino noraida pirms izpildes. Kad prakse rāda, ka aģenta lēmumi tiek pieņemti bez labojumiem, pārskatīšanu beidz.
Kāpēc to neveidot Copilot Studio vai n8n?
Vienkāršām darbību secībām, piemēram, „izlasīt e-pastu, izveidot uzdevumu“, tie ir piemēroti, un mēs tos ieteiksim. Ja aģenti fonā masveidā maina naudas summas, cenas un pasūtījumus, vajadzīgs operāciju katalogs, pielaides, izpildes turpināšana pēc kļūmes, soļu ar neskaidru iznākumu pārbaude un izmaiņu atsaukšana. Šādos konstruktoros šo iespēju nav.
Nākamais solis
Pastāstiet, kurš process aizņem visvairāk laika.
30 minūtēs izstāstīsim, kuras procesa daļas aģents var izpildīt patstāvīgi, kur palīdzēs komandai ātrāk atrast atbildes, kāds būtu tā darba iecirknis un cik izmaksātu pirmais posms. Parādīsim platformas darbību reālā piemērā.
Aprakstiet vienu procesu
Labāk sarunāties?
Rezervējiet 30 minūšu sarunu ar mūsu uzņēmuma vadītāju. Pastāstiet par procesu, mēs uzdosim jautājumus.
Pieteikt 30 minūšu sarunuE-pasts
sergey@binitex.comRiga · Daugavpils, Latvia