AI / ML in Commerce ·

Where AI Actually Fits in Commerce Architecture Right Now

Every commerce platform vendor has an AI story right now. Most of it is marketing. Some of it is genuinely useful. The hard part is knowing which is which before you’ve committed six months of engineering to find out.

I’ve spent the last two years watching AI get layered into commerce stacks — as a practitioner, not an observer. Here’s my honest take on where it actually delivers.

What’s Working in Production

Search and merchandising. This is the clearest win. Vector search on top of your product catalog, combined with behavioral signals, meaningfully improves relevance. Not 10% better — often 30-50% improvement in click-through on search results. SAP CX now has tooling here (the AI Toolkit we demoed internally last year), and the third-party options (Algolia NeuralSearch, Constructor) are mature enough to trust with production traffic.

The architecture decision: do you bolt on a third-party search layer, or do you bet on your platform vendor’s native AI capabilities? My current default is third-party for established stacks — the specialized vendors have 3-4 years head start on training data and model quality. Platform-native AI is catching up but isn’t there yet.

Email personalization. Emarsys’s AI send-time optimization and content personalization actually work. The integration work to connect SAP Commerce transaction data to Emarsys is non-trivial (I’ve done it — the revenue attribution piece alone requires careful event modeling), but once the data pipeline is clean, the AI layer delivers measurable lift on email revenue.

Demand forecasting and inventory. Less visible to the storefront, more valuable to the business. ML models trained on 2-3 years of transaction history can predict stockouts and overstock situations with enough accuracy to meaningfully reduce carrying costs. This is still mostly custom work — I haven’t seen a commerce platform do this out of the box at a level I’d trust.

What’s Still a Science Project

Conversational commerce. The demos are impressive. The production implementations I’ve seen are fragile. LLMs are great at answering product questions when the query is clean. They’re bad at handling the long tail of real user behavior — misspellings, contradictory requirements, “I don’t know what I want but I’ll know it when I see it.” The handoff back to standard browse/search when the conversation breaks is still awkward.

I expect this to be a real capability in 18-24 months. It’s not reliable enough to put in the critical path today.

AI-generated product content at scale. Works for simple products with structured attributes. Breaks down for complex B2B products where precision matters and errors have real consequences. If you’re selling nuts and bolts with 200 technical specifications per SKU, AI content generation needs a lot of human review in the loop before it’s production-grade.

The Architecture Question Nobody Asks Early Enough

Where does the AI layer sit, and who owns it?

This sounds like an IT question. It’s actually a business question. AI capabilities in commerce sit at the intersection of marketing (who wants the personalization), merchandising (who owns the catalog), and engineering (who maintains the integration). When nobody owns it, nobody maintains it, and the AI investment rots.

The cleanest implementations I’ve seen have a dedicated “commerce data” owner — someone whose job is specifically the data pipeline that feeds the AI layer. Not an ML engineer, not a platform admin. Someone who understands both the commerce domain and the data quality requirements.

If you don’t have that person before you start the AI integration, you will before you finish it. Budget for them upfront.

What I’m Watching

The SAP CX AI Toolkit is interesting because it’s trying to make AI capabilities available without requiring a separate ML infrastructure investment. Whether it lives up to that in production at scale is something I’ll know more about over the next 12 months.

The more interesting trend is AI-assisted development tooling for commerce implementations — GitHub Copilot and similar tools are already changing how commerce customization work gets done. I’ve rolled this out on projects and the productivity impact on boilerplate-heavy SAP Commerce extension work is real. That’s a different kind of AI in commerce, but it’s the one that’s affecting how I work right now.

The signal-to-noise ratio on AI in commerce will improve. The vendors who can show production numbers — not demo metrics — will separate from the ones who can’t. Ask for production case studies. Be skeptical of anything without them.