AI in E‑commerce: Where It Helps and Where It Doesn't

Short answer: start with one repeated task that already has clean data and a clear owner. Good first candidates are product data cleanup, support triage and internal reports. Keep a person in the loop for anything that touches prices, refunds or customer promises. Fix the data before you add a model.

This guide is for e-commerce managers and the agencies that advise them. It explains where AI fits and where it isn't worth the effort yet.

What does AI mean in an e-commerce project?

Most useful AI features do one of four jobs:

• Generate: draft product descriptions, translations or support replies.
• Classify: sort support messages, tag products or flag unusual orders.
• Retrieve: find the right product, policy or document for a question.
• Summarise: turn a long thread, a report or a set of reviews into short notes.

Name the job before you choose a tool. A question about a return policy needs the real policy text. A model that only generates text will write a confident answer that may be wrong.

Many tasks need no model at all. A rule, a better filter or a scheduled export often does the job for less.

Where does AI help first?

Product data cleanup

Supplier data is often inconsistent. Titles follow different patterns, and attributes hide in free text.

A model can propose structured attributes, consistent titles and translations. A person or a validation rule accepts each change before it reaches the store.

This work pays off in several places at once. Search, filters, feeds and product pages all read the same product data.

Support triage and draft replies

A model can tag incoming messages by topic, such as delivery, returns or sizing. It can fetch the order status and the matching policy. Then it drafts a reply for a support agent.

Keep the agent as the sender at first. Move simple questions to self-service only when the drafts are reliably correct.

Internal reports and checks

Operations teams spend a lot of time on exports and repeated checks. Automation can collect the data, run the checks and send a short summary.

Often this part needs no AI. A scheduled job with a clear rule is cheaper and easier to test. Add a model only where language matters, such as grouping free-text return reasons.

Search, with a condition

Semantic search can help with vague queries, such as a gift for someone who likes coffee. It still depends on product data and a working search index.

If search results are poor today, check attributes, synonyms and stock data first. A model can't fix fields that are missing.

Where is AI not worth it yet?

• Autonomous chat with refund or discount rights. A wrong answer costs money and trust. Start with drafts that an agent approves.
• Low-volume tasks. If a task happens a few times a month, a checklist is cheaper than an integration.
• Tasks without source data. A model can't know a delivery date that your systems don't store.
• Unreviewed product content. Models can invent materials, sizes or claims. For some product types, that also creates legal risk.

Where should the AI step sit in your stack?

Keep the AI step outside the store itself. A small service reads from your platform, calls the model and writes back approved results. This works the same way on Shopify, MedusaJS or a custom stack.

We split that service into three parts:

• Context: code that collects the product, order or policy data the task needs, and nothing more.
• Model call: the prompt, the model and a check that the output has the expected format.
• Rules: permissions, approval steps and a fallback when the model is unsure or the output fails the check.

Each part can then be tested on its own. When results get worse, you can see whether the data, the prompt or a rule changed.

What risks should you plan for?

Prompt injection is the main security risk. A customer message or a product review can contain text that tries to change the model's instructions.

OWASP lists prompt injection first in its Top 10 for LLM applications. OWASP also notes that a complete prevention method may not exist, so design for it.

• Give each AI feature access only to the data and actions it needs.
• Require a person to approve refunds, price changes and messages that promise something.
• Log inputs, outputs and prompt versions. When results change, you need to know why.

Customer data needs care too. Check what your AI provider stores, where it processes data and whether you have a data processing agreement.

If customers talk to an AI system directly, tell them. The EU AI Act requires this unless it is obvious from the context (Article 50).

How should you start?

1. Pick one task that repeats often and has a clear owner.
2. Write down how long it takes today and how errors are found.
3. Check that the data exists and that you can reach it through an API.
4. Build the smallest version, with a person approving each output.
5. Compare the result with your notes after a few weeks. Then keep it, change it or stop it.

Stopping is a valid result. A small test that shows AI doesn't help saves you from a larger build.

How we help with AI and automation

We connect the tools you already use and build internal tools around them. Where AI helps, we add it inside that work. Examples are a classifier in a support flow or an enrichment step in a product data sync.

AI isn't a separate product for us. It is one option within integrations and automation. If a rule or a scheduled job does the task better, we build that instead.

Tell us what you are building, your current systems and where you need development support. Discuss a project.