AI-agenter i Shopify: Avklar tilganger før de endrer ordrer

Shopify AI Agents: Set Permissions Before They Change Orders

Før du lar AI-agenter i Shopify endre en ordre eller gi butikkreditt, må du bestemme hva de får gjøre når en forespørsel er uklar. Det er viktigere enn hvor imponerende demonstrasjonen ser ut. En nyttig agent kan redusere rutinearbeidet. En agent med for vide tilganger kan gjøre en misforstått melding til en økonomisk korrigering teamet ditt må rydde opp i. Slik ville vi definert tilganger, valgt mellom AI og vanlig automatisering og testet feilhåndtering før agenten får skrivetilgang.

Hvorfor AI-agenter i Shopify trenger klare fullmakter

Practical Ecommerces novemberartikkel, Hvem har ansvaret for feilene til en AI-agent?, setter ansvar foran funksjonalitet. Hovedspørsmålet er hva agenter får gjøre, og hvem som fortsatt står ansvarlig. For en nettbutikk på Shopify blir dette et konkret krav ved innkjøp: Kan verktøyet håndheve rutinene dine, eller lover det bare å følge instruksjoner?

Vi skiller mellom en assistent som foreslår en handling, og en agent som utfører den. Et forslag til ordreendring gir en medarbeider mulighet til å fange opp en feil. En utført endring kan allerede ha påvirket lagerarbeidet eller kundekommunikasjonen.

Fullmaktene til en AI-agent er handlingene den kan utføre uten ytterligere godkjenning. Definer disse separat fra agentens lesetilgang. Tilgang til ordrehistorikk er ikke i seg selv en grunn til å gi tillatelse til å endre en ordre.

Vårt standpunkt er enkelt: Betal bare for selvstendig utførelse der du kan forklare hva som er tillatt, kontrollere resultatet og håndtere feil. Det operative ansvaret bør ligge hos en navngitt person. Juridisk ansvar avhenger av avtalen og gjeldende lovgivning. Leverandørens påstander om automatisering avgjør ikke dette.

Velg forutsigbar automatisering før fri tolkning

Nyere verktøyoversikter gir et nyttig sammenligningsgrunnlag. Yotpos veiledning til drift av nettbutikker inkluderer Shopify Flow og beskriver betingede arbeidsflyter som kundetagging og lagervarsler. Dette er nyttige funksjoner, men betinget logikk trenger ikke en AI-modell til å ta hver eneste beslutning.

Hvis regelen din er «varsle innkjøpsansvarlig når lagerbeholdningen faller under den godkjente grensen», bør du starte med regelstyrt automatisering. Betingelsen er tydelig. Teamet kan undersøke den når noe går galt. Tilknyttede handlinger må fortsatt testes, og tilgjengeligheten avhenger av appene som brukes, men det er liten grunn til å legge tolkning oppå en klar regel.

AI blir mer nyttig når innholdet må tolkes. En kunde kan beskrive et adresseproblem uten å bruke begrepene dere bruker internt. En agent kan kategorisere henvendelsen og klargjøre relevante opplysninger for gjennomgang. Det betyr ikke at den også bør få endre leveringsadressen.

Shopifys veiledning til AI i varehandelen beskriver AI-genererte hurtigsvar og svarforslag i Shopify Inbox. Svarforslag illustrerer et nyttig skille: Programvaren kan forberede arbeidet, mens et menneske beholder kontrollen over det som sendes. Bruk det samme skillet for driftsoppgaver.

Hvem bør velge bort et autonomt verktøy?

Velg det bort hvis teamet fortsatt er uenig om reglene som skal ligge til grunn. Hvis medarbeidere håndterer identiske forespørsler ulikt, vil ikke en agent løse uenigheten på en trygg måte. Nettbutikker med få henvendelser kan også oppleve at godkjenningskøer og vedlikehold av integrasjoner krever mer arbeid enn verktøyet sparer. Start med en arbeidsflyt som bare gir anbefalinger, til det finnes en tydelig grunn til å utvide.

Definer tilganger for AI-agenter i Shopify per handling

Ikke godkjenn en bred kategori som «ordrehåndtering». Del den opp i enkelthandlinger. Å lese leveringsstatus og å kansellere en ordre har svært ulike konsekvenser.

For hver foreslåtte handling bør du dokumentere hvilke data den trenger, hvilke rammer som gjelder, og når den skal sendes til en person for vurdering. Dokumenter også disse reglene utenfor agentens prompt. Teamet trenger et felles regelverk som ikke forsvinner når noen redigerer automatiseringen.

Kun lesing: Hent relevant ordrestatus eller oppsummer en intern sak. Begrens dataene som returneres, til det oppgaven krever.
Kun utkast: Foreslå en korrigering eller klargjør et svar. Ingenting endres før en person med nødvendig fullmakt har godkjent det.
Utførelse innenfor definerte rammer: Utfør en uttrykkelig godkjent handling når alle nødvendige kontroller er bestått. Manglende informasjon sender oppgaven til manuell vurdering.
Kun manuell behandling: La bare medarbeidere med nødvendig fullmakt håndtere sensitive unntak og endringer i agentens egne tilganger.

Sett beløpsgrenser ut fra egne retningslinjer og marginer, fremfor å kopiere leverandørens standardinnstillinger. Definer om en grense gjelder for en enkelt transaksjon eller kundens samlede aktivitet. En grense per handling gir svak beskyttelse hvis samme forespørsel kan utløse handlingen flere ganger.

Instruksjoner erstatter ikke teknisk håndhevet tilgangskontroll. Spør leverandøren hvor hver begrensning håndheves. En regel i en prompt kan påvirke atferden. En tilgangskontroll utenfor modellen kan avvise en handling som ikke er tillatt. Shopifys tilgangsomfang dekker ikke nødvendigvis alle forretningsreglene du trenger, så integrasjonen kan kreve ekstra kontroller.

Gjør godkjenningen konkret nok til å ha verdi

En knapp merket «Godkjenn» er ikke tilstrekkelig hvis den som vurderer saken, ikke kan se hva som vil skje. Godkjenningsvisningen bør vise den berørte ordren, den foreslåtte endringen og grunnlaget for den. Ved økonomiske handlinger må beløp og valuta vises tydelig.

Knytt godkjenningen til akkurat dette forslaget. Hvis ordren endres før handlingen utføres, bør integrasjonen kontrollere den på nytt og be om ny godkjenning ved behov. Ellers kan noen godkjenne en adresseendring mens lageret allerede behandler den opprinnelige forsendelsen.

Kundemeldinger og importerte dokumenter er inndata, ikke fullmakter. En melding som ber agenten ignorere butikkens regler, må ikke få myndighet bare fordi modellen leser den. Test dette bevisst, fremfor å anta at leverandøren har tatt hånd om det.

Spør også hva som skjer når godkjenningstjenesten er utilgjengelig. Vårt utgangspunkt ville vært å sette oppgaven på vent. Et system som fortsetter uten varsel fordi det ikke får tak i en godkjenner, motarbeider selve formålet med godkjenningen.

Bruk transaksjonsnotater som dokumentasjon, ikke som hele revisjonssporet

En konkret Shopify-oppdatering gjør temaet aktuelt. I Shopifys endringslogg for interne notater på butikkreditt-transaksjoner står det at versjon 2027-01 av GraphQL Admin API legger til et valgfritt notat, kun synlig for forhandleren, ved kreditering og debitering av butikkreditt. Integrasjoner kan lese lagrede notater på krediterings-, debiterings- og reverseringstransaksjoner for debiteringer.

Notatene støtter opptil 5 000 tegn. Lengre notater returnerer brukerfeilen NOTE_TOO_LONG, og API-et oppretter ikke transaksjonen. Utløpstransaksjoner returnerer alltid null. Transaksjoner uten notat returnerer også null. Eksisterende integrasjoner trenger ingen endringer, fordi feltet er valgfritt.

For nettbutikker gir dette et sted å lagre begrunnelsen sammen med en økonomisk justering, når integrasjonen bruker denne API-versjonen. Vi ville inkludert en kort begrunnelse og en intern saksreferanse, samt en referanse til godkjenningen der det er relevant. Unngå å kopiere hele kundesamtaler eller unødvendige personopplysninger inn i feltet.

Ikke behandle et notat som bevis på at en handling var godkjent. Oppbevar dokumentasjon på godkjenning og utførelse separat. Utvikleren bør også validere notatlengden før transaksjonen sendes inn, slik at en for lang forklaring ikke blokkerer den planlagte justeringen.

Test usikre utfall, ikke bare vellykkede forespørsler

Kjør arbeidsflyten i et egnet testmiljø med kontrollerte data før den får utføre reelle økonomiske handlinger. En polert demonstrasjon følger vanligvis det forventede forløpet. Akseptansetestene bør fokusere på det som skjer utenfor dette forløpet.

Uklar ordreidentifikasjon: Forespørselen kan gjelde flere ulike ordrer. Agenten bør be om en avklaring i stedet for å velge selv.
Gjentatt forespørsel: Den samme hendelsen kommer inn på nytt. Bekreft at den ikke kan gi dobbel butikkreditt eller gjenta en endring.
Endret ordrestatus: Ordrebehandlingen går videre etter at forslaget er laget. Kontroller at handlingen bare utføres hvis den fortsatt er tillatt ut fra gjeldende status.
Usikkert API-svar: Handlingen kan ha lykkes, men bekreftelsen mangler. Kontroller tilstanden før et nytt forsøk.
Motstridende instruksjoner: En kundemelding ber systemet om å omgå reglene. Bekreft at de tekniske begrensningene fortsatt gjelder.

Be leverandøren demonstrere disse tilfellene. En funksjonsliste forteller ikke om nye forsøk er trygge. Hvis verktøyet ikke kan vise hva det forsøkte å gjøre, og hva Shopify bekreftet, bør det ikke få utføre økonomiske handlinger.

Planlegg stopprutinen før lansering

Velg en arbeidsflyt der feil er lette å oppdage, og konsekvensene kan begrenses. Start med foreslåtte handlinger, og sammenlign dem deretter med medarbeidernes beslutninger. Registrer hvorfor forslag blir avvist. Disse begrunnelsene avdekker manglende regler bedre enn en overordnet påstand om treffsikkerhet.

Mål oppryddingsarbeidet, ikke bare tiden dere sparer. Opphopning i godkjenningskøen og forsøk på å utføre samme handling flere ganger er nyttige driftssignaler. En agent som fullfører oppgaver raskt, men skaper vanskelige unntak, kan gi teamet merarbeid.

Gi en person myndighet til å stoppe utførelsen. Dokumenter hvordan arbeid i kø settes på pause, og hvordan handlinger med usikkert utfall undersøkes. Test rutinen. Feilretting kan kreve en kompenserende handling eller kontakt med kunden, fremfor en enkel angring.

Utvid tilgangene først når dokumentasjonen gir grunnlag for det. Vi vil heller se en avgrenset arbeidsflyt teamet stoler på, enn vide tilganger ingen trygt kan forklare.

Viktige punkter

Definer fullmakter for hver handling før AI-agenter i Shopify får skrivetilgang.
Bruk betinget automatisering der regelen allerede er tydelig.
Håndhev begrensninger utenfor modellen, og knytt godkjenningen til en konkret foreslått endring.
Bevar bakgrunnen for transaksjonen, og dokumenter godkjenning og utførelse separat.
Test dupliserte forespørsler og usikre utfall før agenten får større handlingsrom.

Kilder

Vil du ha hjelp med dette?

Vi er Shopify Premier Partner og jobber med dette hver dag: ytelse, konverteringsoptimalisering og utvikling av nettbutikker som lønner seg. Bestill en gratis gjennomgang av nettbutikken, så viser vi deg de tre forbedringene vi ville gjennomført først.

Ofte stilte spørsmål

Hvordan bør jeg sette tilganger for AI-agenter i Shopify?

Definer tilganger per handling, ikke for en bred rolle som ordrehåndtering. Skill lesetilgang fra tillatelse til å utføre handlinger, håndhev forretningsregler utenfor modellen, og krev godkjenning for sensitive unntak.

Når bør jeg bruke Shopify Flow i stedet for en AI-agent?

Start med Shopify Flow når oppgaven følger tydelige betingelser, for eksempel å sende et lagervarsel. AI er mer nyttig når innhold må tolkes, men det å tolke en forespørsel krever ikke at modellen får tillatelse til å utføre handlingen.

Kan butikkreditt-transaksjoner i Shopify ha interne notater?

Ifølge Shopifys endringslogg støtter versjon 2027-01 av GraphQL Admin API valgfrie notater, kun synlige for forhandleren, ved kreditering og debitering av butikkreditt. Notatene støtter opptil 5 000 tegn. Lengre notater gir feilen NOTE_TOO_LONG, og transaksjonen blir ikke opprettet.

Hva bør jeg teste før en AI-agent får endre Shopify-ordrer?

Test uklare ordrereferanser, dupliserte forespørsler, endret leveringsstatus og manglende API-bekreftelser. Kontroller også at instruksjoner fra kunder ikke kan omgå reglene, og at teamet kan sette handlinger i kø på pause.