In the first part of this series, the focus was on the current challenges of test data management: functionally demanding requirements, distributed data landscapes, data privacy, organizational coordination, and the question of how XDM already supports these tasks today.
XDM covers the path from modeling relevant data sources to selecting and providing suitable test data.
The obvious question now is: What could the next step look like?
If test data can already be provided today through defined processes, search mechanisms, and request interfaces, the next evolution is easy to imagine: What if developers and testers could formulate their needs directly in natural language in the future?
This is exactly where an interesting interaction between LLM, MCP, and XDM begins to emerge.
Requesting test data by prompt
One possible future scenario can be described quickly: A developer is working in their IDE or using an internal assistant and formulates their request directly in business language:
I need 10 motor insurance contracts where more than two claims were reported in the last year and the policyholder has several active contracts.
Please provide these cases in my test environment.
In such a workflow, an LLM would interpret the business intent of the request and convert it into a structured requirement.
Via an MCP server, suitable XDM functions could be connected as tools.
XDM would then take over the operational execution, for example by:
- translating the request into search and selection criteria
- identifying suitable data constellations
- triggering defined provisioning processes
- modifying sensitive content based on rules
- transferring the data into a target environment in a controlled way
The key difference would therefore not lie in a new copy mechanism, but in a new form of interaction: The user describes their business need, and the system derives the technical implementation from it.
XDM as the operational layer behind the prompt
It is important to understand the roles correctly here: an LLM would not replace test data management, but make access to it easier.
The reliable operational layer would remain XDM.
This is where the modeled applications reside, along with the relationships between data, the logic for search and provisioning, and the rules for modification and process execution.
Even today, XDM is designed for self-service and demand-driven provisioning, for example through the Data Shop.
In an AI-supported scenario, the platform itself would therefore not be replaced.
What would mainly be extended is the user interaction: instead of filling out a request form, a user could describe their need directly.
From form to dialog
This is precisely where a significant added value lies.
Self-service today usually works through predefined input forms.
That makes sense, and in many scenarios it will continue to be the right approach.
With the Data Shop, XDM already provides an established mechanism through which end users can request defined processes.
However, an LLM-supported approach could add another layer to this logic: dialog.
Instead of navigating fields, parameters, and technical terminology, users could describe in their own language what they need from a business perspective.
The LLM would interpret that description, ask follow-up questions if needed, clarify missing details, and then convert the request into a structured execution.
For developers and testers in particular, this would be a practical step forward.
The process of requesting test data would align more closely with the way they actually work and could be integrated more naturally into existing development and testing workflows.
MCP as the intermediary between AI and XDM
For an LLM not only to generate text, but also to trigger targeted actions in operational systems, it needs a clearly defined and controllable integration layer.
This is where MCP can play an important role: as the mediation layer between the language model and XDM functions.
In such an architecture, the LLM would not access databases or processes directly, but would interact with XDM through defined interfaces.
XDM already provides the necessary technical integration options through APIs, workflows, and other callable functions.
In this model, MCP would therefore not be the actual test data management system, but the connection layer through which an LLM can address suitable XDM functions in a targeted way.
This separation is particularly relevant from the perspective of governance, traceability, and controlled execution.
The more natural language becomes the entry point for operational processes, the more important clear technical responsibilities in the background become.
Making business-oriented search far more accessible
A particularly obvious use case is the business-oriented search for suitable test cases.
With Test Data Finder, XDM already provides a foundation for identifying suitable data constellations in heterogeneous environments.
An LLM could build on this and accept search requests not only through prepared fields, but also through naturally phrased descriptions.
This is especially relevant where the business need is clear, but cannot easily be translated into concrete search parameters.
Instead of operating search forms manually, the user could first describe the case they need.
The system would derive a more precise search query from that description, ask follow-up questions if required, and then pass the identified constellations directly into provisioning.
This can make access to test data noticeably easier, especially in mature system landscapes where business logic, data structures, and technical selection logic are not always aligned.
Support directly in the IDE
This future picture becomes even more interesting when it does not stop at data provisioning.
For example, it is conceivable that a developer could formulate directly in their IDE:
Generate test scaffolding for claims handling using realistic contract and claims constellations from the motor insurance domain.
In such a scenario, an LLM could request functionally plausible data patterns through XDM and then use them to suggest test code, fixtures, or sample data for test cases.
The value here would not lie in convenience alone.
Tests could be aligned more closely with real business constellations than many manually created dummy scenarios.
By using more realistic test data in unit tests, potential defects can be identified earlier that would otherwise not be represented or considered with mocked or synthetic data.
At the same time, central control of data logic, modification, and provisioning would remain anchored in the platform designed for exactly that purpose.
For teams working under time pressure while still needing reliable tests, this would be a relevant step: less friction in day-to-day work without giving up control over data and processes.
The prompt as the new request interface
The biggest change here might therefore be less technical than organizational and cultural.
Until now, users have often had to adapt to the logic of the systems: understand forms, set parameters correctly, know technical structures, or follow existing processes in detail.
That makes sense in stable procedures, but in everyday work it also creates friction.
In the future, the system could align more closely with the user’s language:
- The prompt would become the request interface.
- The LLM would become the interaction layer.
- MCP would handle the mediation.
- XDM would remain the platform that controls, governs, and makes the actual execution traceable.
What changes here is therefore not the business or technical responsibility, but primarily the way access is provided.
Conclusion
The next step in test data management may lie less in replacing existing platforms and more in making them more accessible through more natural forms of interaction.
XDM already brings together many of the building blocks on which such a scenario could be based: modeled applications, search and provisioning mechanisms, self-service, modification, and process integration.
What would be new is mainly the form of interaction.
No longer form and parameter logic first, followed by business context — but instead the business description first, with the technical execution built on top of it.
For developers, testers, and IT decision-makers in particular, this offers a clear and practical benefit: less translation effort between business requirements and system logic, more direct access to suitable test data, and at the same time a controlled operational foundation in the background.
