Large fashion groups do not buy a single AI design tool; they build the layer underneath one. That layer is identity and tenancy, governed access to their own product data, one audited route to models, and an evaluation step — after which product teams and non-engineers can assemble small tools on top without handing anything to an outside API. Otto Group is a useful case to reconstruct because the group owns both halves of the problem: retail brands that want the tools, and in-house IT and consulting units able to run the platform those tools sit on.
Key takeaways
- At group scale the unit of adoption is a platform, not a tool: one governed path to models, many small tools on top of it.
- Where your product data is allowed to sit decides which models you can call, so data placement is an architecture decision before it is a legal one.
- Non-engineers ship useful tools only when the default path is already safe: pre-approved models, scoped data, logged inputs and outputs.
- The weak point in most group AI programmes is measurement, not capability.
Why does proprietary product data block the obvious approach?
The requests are always the same: variations on last season's best jacket, fit complaints summarised by size run, a tech pack rewritten against a new supplier's capabilities. Each is simple in isolation, and each needs the group's own files — pattern geometry, graded sizes, cost sheets, supplier terms, returns history. Paste that into a consumer chat window and you have exported your margin structure into a system you do not control, under terms you never negotiated. So legal says no, the tool never ships, and the work goes back to being done by hand, or gets done anyway on a personal account, which is worse because you cannot see it.
The exposure is not hypothetical, and it is not always the vendor whose contract you signed. In August 2026, two makers of hardware crypto wallets disclosed that thousands of their customers had personal and shipping details stolen through breaches at shipping providers rather than in the makers' own systems, which is what a subprocessor chain looks like when it fails. Your vendor's vendors inherit your risk whether or not you can name them.
Why do the usual fixes fail?
- A tool per brand. Parallel contracts, parallel data-processing agreements, a copy of the same archive behind each one. Nothing composes, and the security review restarts from zero every time.
- One central AI team. Demand outruns headcount immediately, so a tool that would have helped during line review lands after the range is locked.
- A ban. Usage moves to personal accounts, where you cannot log it, scope it or improve it.
What all three miss is that the change is organisational before it is technical. That argument is made well in an essay on AI-native operating models published in August 2026: for companies assembled by acquisition, the difficulty is the accumulated systems and the operating model around them, not the model call itself. Fashion groups are assembled exactly that way, so the reasoning transfers.
What does Otto Group's structure tell you about where the platform sits?
Otto Group is not a single shop. It is a set of retail brands sitting on shared logistics, financial services and in-house IT and consulting units, and the group is actively pushing AI capability into commerce across those brands. That answers the location question by itself: the platform belongs to the technology arm, and the brands are tenants on it.
If brands are tenants, tenancy is the first thing you design, not something you retrofit once the second tool ships. A tenant is a boundary for data, cost attribution, model choice and audit, and every later tool inherits whatever you got wrong.
The same order of operations shows up elsewhere in European fashion e-commerce. Zalando runs a public engineering practice, is pushing agentic engineering internally, and sells platform services — logistics, software, marketplace infrastructure — to other brands. Different business model, identical instinct: build the platform, then let the tools appear on it.
What is actually in the platform, layer by layer?
| Layer | What it does | Why it matters at group scale |
|---|---|---|
| Identity and tenancy | Resolves a user to a brand, a role and a data scope | One over-broad scope crosses brand boundaries silently |
| Data plane | Serves governed reads of patterns, tech packs, sales and returns | Tools inherit permissions instead of copying archives around |
| Model gateway | One audited route to hosted and privately deployed models | You can change models without rewriting the tools |
| Tool runtime | Executes whatever a non-engineer assembled | Prompts, inputs and outputs are logged by default, not by discipline |
| Evaluation | Scores output against house rules and past seasons | Product judgement becomes testable instead of argued in a meeting |
The gateway is the layer most groups buy rather than build. Azure OpenAI, now offered within Microsoft's Foundry platform, occupies that slot for enterprise buyers because it ships what a governance review asks about: hosted access to foundation models plus fine-tuning, agent orchestration, content moderation, and enterprise security and compliance tooling. A gateway is more than a proxy — it is where quotas, redaction, model allow-lists and per-tenant logging attach.
The data plane is the harder half, and it is where a lakehouse-style platform lands. Databricks is representative of that layer today: a unified data and AI platform with serverless Postgres alongside the lakehouse, data-aware analytics agents, and an explicit surface for building and operating enterprise agents. The reason to consolidate is unglamorous — an agent is only as good as its read path, and a read path built per tool is one nobody can audit.
One decision cuts across both layers: which models may see which data. Open-weight models you run yourself and stronger models behind a provider's API are not interchangeable here. A private deployment lets you point a model at archives you would never send outside; a hosted flagship model gives capability you cannot match in-house. Most platforms carry both, with the gateway deciding what a given tool and tenant can reach.
How do non-engineers build tools without touching a model directly?
The pattern that works is a catalogue, not a blank prompt box. Five steps:
- Pick a template. Summarise, extract, classify, generate variations, check against a rule set. Each arrives with a model, a system prompt and an output schema attached.
- Choose a data scope. The builder selects from connectors their role already permits. There is no upload step, because uploading is how archives escape.
- Write the instruction and examples. The part a designer or merchandiser is genuinely best at: what good output looks like in their category.
- Attach a check. A handful of cases with expected answers. If the tool cannot pass them, it does not publish. This is the step platforms skip most often and regret first.
- Publish to a tenant. The tool appears for one brand or team, with usage and cost visible to whoever owns that budget.
That is how you get a fit-comment summariser owned by merchandising, an artwork variation tool that reads only approved prints, or a tech-pack checker that flags a measurement table contradicting its own size chart. None need an engineer. All need the layers underneath.
What changes, and what is still open?
Procurement changes first: one platform contract replaces a growing set of point tools, and cost moves from seat licences to tokens and compute — harder to forecast, easier to attribute. The security question is also asked once at the platform boundary rather than once per vendor, and it gets concrete. Which scope, which model, which logs.
- Measurement. Groups rarely publish tool-by-tool outcomes, so your own evaluation history is the only honest scoreboard you will have.
- Geometry. Retrieval over text is mature; retrieval over pattern and CAD data is not. Grading rules and construction logic are not paragraphs, and treating them as paragraphs produces confident nonsense.
- Ownership. A tool built by someone who later changes role becomes an orphan, and platforms that assign no maintainer accumulate abandoned tools fast.
- Model churn. Every model swap silently re-scores your evaluation suite. Without the suite, you cannot tell an upgrade from a regression.
FAQ
Does an internal AI platform mean self-hosting every model? No. It means owning the route to models. Most groups combine a hosted gateway for capability with privately deployed models for data they will not send out, then let the gateway enforce which tool reaches which model.
Can non-engineers really build production tools? Yes, inside templates. They supply the domain instruction, examples and test cases; the platform supplies the model, the data scope, the output schema and the logging. Free-form prompt boxes over unscoped data are what fail.
Do you need a data platform before a model gateway? You can start with the gateway, and most teams do. Value stays shallow until governed reads of your own product data exist, because a model with no access to your archive is a general assistant, not an internal tool.
How do you stop one brand's data reaching another brand's tool? Tenancy, scoped connectors and logs. A user resolves to a brand and role, connectors expose only what that role may read, and every call is recorded, so an over-broad scope becomes visible instead of theoretical.
Further reading
- Why the open-weight and API-only split decides what a private deployment can use — one provider running both strategies at once.
- Service standards as an operations problem, not a marketing one — a marketplace tightening refunds, stock guarantees and delivery coordination.