Most enterprise AI never leaves the pilot. A promising demo stalls because no one set the guardrails, the wrong tool got picked, or the team could not prove it actually worked. This playbook is the practical path from that first experiment to a governed feature running in production – on Mendix, using the Siemens AI stack. Work through it in order; each phase ends with a checkpoint to tick before moving on. The through-line is control: governing AI is not about slowing it down, it is about making it safe enough to ship and keep.
Who this is for
Teams who have run, or are about to run, an AI pilot and now need a repeatable route to production rather than a leap of faith. If you are adding AI to one application, this is your project plan. If you are governing AI across a portfolio, run it once end to end, capture what you learn, then template it for the rest.
Phase 1 – Frame the use case and decide it is worth doing
The most expensive AI project is the one that should never have started. Before choosing a tool or writing a prompt, be honest about the problem:
- Name the decision or task the AI will assist – “summarise this policy for a claims handler,” “score this transaction for fraud risk,” “answer a supplier’s question from our own data” – specific and bounded, not “add AI to the app.”
- Say what good looks like. What accuracy is acceptable? What is the cost of a wrong answer, and who bears it? If a mistake is unrecoverable, that shapes how much human oversight you build in later.
- Check that AI is the right instrument. A rule, a report, or a simple integration is often cheaper and easier to defend. Use AI where the value comes from language, prediction, or reasoning over messy data – not where a formula would do.
- Confirm you have the data and the right to use it. Grounding an answer, training a model, or retrieving from a knowledge base all depend on data you can access and are permitted to use for the purpose.
Checkpoint: a one-paragraph use case with a named task, a definition of a good answer, the cost of a bad one, and a clear reason AI beats the simpler alternative.
Phase 2 – Choose the right tool on the Siemens stack
Siemens gives you several ways to add intelligence, and picking the wrong one is a common way pilots stall. Match the tool to the shape of the problem:
- Maia – for build-time assistance. If the goal is to build the app faster, Maia is your co-developer inside Studio Pro and the Mendix Portal. Maia Plan turns a brief into epics and user stories; Maia Make generates working domain models, pages, and logic – plus unit tests and validation in the same conversation – from plain language. This speeds up how the app gets built; it is not the runtime feature itself.
- Agents Kit + MCP – for agentic workflows. When the use case is a multi-step task that reasons and acts, build an agent. With Agents Kit 2.0 and the Agent Editor, an agent becomes a versioned, deployable part of the app model: you configure its type, model, prompts, and tools, and wire in tools built from microflows and consumed MCP services. Use the Model Context Protocol in both directions – expose your app’s logic as MCP tools for external clients, and let your agents call tools on external MCP servers.
- RapidMiner AI Studio – for custom ML models. When the value comes from prediction on your own structured data – forecasting demand, scoring churn, predicting defects, detecting anomalies – that is data science, not a prompt. Build and deploy the model in AI Studio, then consume it inside the Mendix app so the prediction reaches the people who act on it.
- Graph Studio / GraphRAG – to ground answers in your data. When an answer must be grounded in connected enterprise data spanning PLM, ERP, CRM, and MES, a knowledge graph gives the model the relationships between things, not just isolated tables. GraphRAG grounds answers in your business rather than in a guess, which means better answers and fewer hallucinations.
These combine. A production feature might use Maia to build the app, an Agents Kit agent to run the workflow, an AI Studio model for a prediction, and Graph Studio to ground the agent’s answers – each doing the job it is best at.
Checkpoint: the use case is mapped to one primary tool, with any supporting tools named, and you can say in a sentence why it fits the problem better than the alternatives.
Phase 3 – Set the guardrails before you build
Guardrails decided after the fact are guardrails that leak. Design them into the feature from the start – this is the phase that turns a clever pilot into something an enterprise can actually run:
- Human-in-the-loop where it matters. Decide which actions a person must approve before they take effect. In Agents Kit, human-in-the-loop approval steps gate tool execution until a user approves, configurable per tool and per knowledge base. Reserve full autonomy for low-stakes, reversible actions.
- Draw the data boundaries. Be explicit about what data the AI may see, retrieve, and send to a model provider. Knowledge base integration is vendor-agnostic, so you can keep sensitive retrieval on an implementation you control, and bring-your-own-model options – Amazon Bedrock, Azure OpenAI, Mistral, Google Gemini, or a custom OpenAI-compatible backend – let you decide where data goes for residency and cost.
- Keep your data out of training. AI features on Mendix run with your data kept out of model training. Make that an explicit requirement of the design, not an assumption.
- Apply Mendix Policies. Govern what AI can do with central policies applied consistently across your applications, so a rule set once holds across the portfolio rather than in one developer’s head.
- Turn on the observability you will need later. End User Telemetry keeps AI usage visible across the portfolio, and agent traces plus LLM trace observability show tool calls and knowledge retrievals. You cannot prove value in Phase 5 without measurement wired in now.
Checkpoint: a short guardrail spec – approval points, data boundaries, the training-exclusion requirement, the policies that apply, and the telemetry switched on – agreed before a line of the feature is built.
Phase 4 – Build and integrate into a governed Mendix app
Now build the feature into the application, where the governance lives. The advantage of doing this on Mendix is that AI-built and hand-built logic sit in the same visual model, held to the same enterprise standard:
- Build the AI layer as part of the app model. Configure the agent in the Agent Editor, test it in the Playground with variable substitution, and call it from business logic with a Call Agent microflow action. Expose or consume MCP tools as the workflow needs. The result is version-controlled and deployable, not a bolt-on script.
- Wire in the model or the graph. Consume an AI Studio model or a Graph Studio foundation through the same governed application layer, so a prediction or a grounded answer flows into a screen, a workflow, or an approval step where someone acts on it.
- Keep the output inspectable. On Mendix the AI’s work is a visual model your team can read and reason about rather than opaque code, so it can be reviewed, secured, and maintained like the rest of the app – no hidden maintenance bill later.
- Integrate, do not island. Connect the feature to real data and real screens behind your existing security. A pilot that only runs in a sandbox has not been integrated; it has been demonstrated.
Checkpoint: the AI feature runs inside the governed Mendix app, behind its security model, callable from real business logic, with the guardrails from Phase 3 actually enforced.
Phase 5 – Test, measure, and prove value
An AI feature that works in a demo is not the same as one you can trust in production. Prove it against the definition of good you set in Phase 1:
- Accuracy. Evaluate outputs against a known set of cases, including the awkward and adversarial ones. For a model, measure against a held-out sample; for an agent or a grounded answer, review a representative set of real interactions rather than the happy path.
- Adoption. Use End User Telemetry to see whether people actually use the feature and where they abandon it. A technically accurate feature no one trusts has not delivered value.
- ROI. Tie the result back to the cost of the task you named in Phase 1 – time saved, errors avoided, decisions made faster – so the business case is evidence, not a slide.
- Watch it in production. Keep the traces and telemetry on after go-live. Models drift, data changes, and prompts age; observability is how you catch a regression before your users do.
Checkpoint: measured accuracy against real cases, evidence of adoption, an ROI number tied to the original task, and monitoring live for drift – enough to decide, on evidence, whether to scale it.
What trips teams up
- Starting with the tool, not the problem – reaching for an agent or a model before anyone has framed a use case worth doing.
- Picking the wrong instrument – using a chat prompt where a trained model belongs, or a model where a simple rule would do.
- Bolting governance on at the end – approvals, data boundaries, and policies designed after the build leak, and slow the launch down more than doing them up front would have.
- Ungrounded answers – expecting a general model to know your business without Graph Studio or a knowledge base to ground it, then being surprised by hallucinations.
- No measurement wired in – shipping without telemetry or traces, so there is no way to prove accuracy, adoption, or ROI, and no way to spot drift.
- Confusing a demo with an integration – a feature that only runs in a sandbox has not been put into production.
The pre-flight checklist
- Use case named, with a definition of a good answer and the cost of a bad one.
- AI confirmed as the right instrument over the simpler alternative.
- Data available and permitted for the purpose.
- Primary tool chosen on the Siemens stack, with a reason it fits.
- Human-in-the-loop approval points decided for anything high-stakes.
- Data boundaries drawn; your data kept out of model training; model provider chosen.
- Mendix Policies to apply identified; End User Telemetry and traces switched on.
- Success metrics agreed – accuracy target, adoption signal, ROI measure – before the build.
How Golden Earth helps
We are a senior-led Mendix consultancy, and we run this work the way we run everything: senior engineers only, documentation-first, embedded in your team. Our part is the governed Mendix layer – we build the app that puts a model to work, runs the agentic workflow, surfaces the graph, and enforces the guardrails – and we advise on where each piece of the Siemens stack fits your problem. We are not a RapidMiner implementation shop: AI Studio models and Graph Studio foundations are built by your data-science and platform teams or by Siemens, and we make them useful inside production software your business can trust. You own the knowledge at the end, not a black box. If you want experienced hands to take an AI feature from pilot to production, talk to an expert.