How AI makes interfaces fast, affordable and verifiable – and loosens vendor lock-in in the life sciences.
At a glance
- AI lowers the cost of building interfaces to specialised tools so far that purchased add-on modules and connectors now have to justify their price. The ERP core remains standard software.
- A component only becomes replaceable if its functions are addressable, that is, accessible through APIs rather than through screens. How far your own landscape is from that point determines your room to manoeuvre.
- In a GxP environment, documented evidence remains the bottleneck. AI automates the recurring validation effort that used to count against custom software. Approval remains a human decision.
- Recommendation: capture processes and requirements, then implement a validated pilot on a manageable interface.
What is happening right now
At the end of September 2026, the open-source project ArtCraft set out to rebuild seven Adobe applications. Just over a week later, counterparts to Photoshop, Illustrator and Premiere were up and running. What stands out, apart from the speed, is how they are built: the programs are designed not only for people but also for AI agents. Every function is a named command that the user interface, the API and an agent can call in exactly the same way.
For ERP landscapes, this raises an uncomfortable question: if missing functions can be built this quickly and integrated this cleanly, why buy the add-on module at all? The answer depends on how addressable your own landscape is. SAP is moving in this direction with Clean Core, but in many companies decades of custom development and modifications stand between the current state and that target picture.
Lock-in has always been the price
Closed systems hold their ground in the market less because their code is inaccessible than because of cost: developing the missing ten per cent in-house has so far been more expensive than licensing the next module. Companies rarely procure an ERP system for its full scope of functionality. What usually tips the balance is that the gap between existing and required functionality cannot be closed economically any other way. At its core, the customer is paying to close that gap.
What has shifted is the threshold at which a system owner says: we will not build this ourselves. In practice it used to sit at roughly one person-month; below it, companies built, above it, they bought. In our project experience it is now considerably higher and still rising.
The ERP core is not affected. Rebuilding an SAP S/4HANA® system makes no economic sense; the cost comparison further down shows why. What is affected is the layer above it: interfaces and connectors, add-on modules, portals, reporting solutions and workflow extensions. That is the core business of add-on and partner solution vendors.
Composable ERP is no longer just a slideware term
Composable ERP has not failed because of the idea, but because of the interfaces. A decomposed system needs more interfaces, more mapping and more state synchronisation, and every interface used to cost development budget plus a maintenance contract. A single monolithic system was cheaper than many small individual systems.
The interface is no longer the dominant cost item. A mapping between two data models, an adapter for an undocumented interface, a converter for a legacy format: these are clearly scoped tasks with a verifiable result, and therefore exactly the kind of work where AI-assisted development already delivers today. Our article GxP compliance under pressure describes what such an integration layer looks like for GxP processes.
Figure 1 contrasts the two approaches. Companies that fear integration effort source everything from one vendor and accept weak functionality. Once AI makes integration affordable and verifiable, specialised tools that each do their job well can be connected to the ERP core. The figure is schematic.
The consequence is not that everyone will build their own ERP; it is that life gets less comfortable for software vendors: the price of an interface can no longer be justified by its complexity. A vendor that licenses per connector is selling something the customer can now build in-house and whose effort the customer can calculate.
The limit lies in domain know-how. Batch traceability, serialisation under the EU FMD, release logic, twenty years of accumulated special cases in a material master: that is not a coding problem but a domain problem. AI lowers the cost of writing code, not the cost of knowing what to write.
The architecture that makes this possible
PhotoCraft, ArtCraft's Photoshop counterpart, is agent-ready not because it contains AI, but because every business function is available as an addressable interface. The user interface, the command line, the control channel and the MCP server all call the same implementation (Figure 2). This is not a passing trend but the oldest clean separation in computer science, and it determines whether systems are replaceable.
In practice, this means the process is modelled where it belongs from a business perspective: in BPMN, readable and reviewable. Technical execution sits in the automation layer. The data remains in the systems of record.
This concept has already broken the lock-in at the decisive point, long before anything is designed in-house. Replacing a component then becomes a question of adapters, not of migration projects.
For SAP landscapes, this means Clean Core: extensions access the core through released interfaces such as OData, events or BAPIs instead of modifying it. They run on SAP® Business Technology Platform (SAP BTP) or in the automation layer. This is the only way an extension stays replaceable and survives releases of the core without being redeveloped.
In a system whose functions can only be reached through screens, even the best AI is of little use. All it can do is click. A click path can neither be specified nor reproduced, which makes it the worst of all options in a regulated environment.
What counts in regulated environments
The project itself names a key limitation: every menu item is connected, but the parity table only checks whether a function can be called, not whether it works correctly from a business perspective.
In GxP environments, the cost of design and implementation is not the problem. Validation, lifecycle and operation are. AI lowers these costs too, but unevenly. Validation itself does not improve quality; it provides the evidence. A defect-free system needs the same documented evidence as a system with defects.
It is precisely the recurring lifecycle effort that used to count against custom software: deriving test cases from specifications, maintaining traceability, pre-sorting deviations, preparing trend analyses and periodic reviews. These tasks can now be largely automated and performed continuously rather than once a year. This is where the underestimated benefit of AI in a regulated environment lies.
The decision itself cannot be automated. Accountability remains with whoever confirms and approves correctness. Particular care is required when specification, code and test cases are all generated by the same model. A passed test then merely shows that the artefacts are consistent with each other; it does not demonstrate that the system meets its requirements. Independent verification is therefore a substantive prerequisite for robust validation. Test cases must be derived from the requirements specification, not from the implementation. The expected results are defined by a responsible subject matter expert or by a separate process.
The economics still tip in favour of building in-house, but for a different reason than the hype suggests (Table 1):
Table 1: Purchased module vs. AI-assisted integration
| Purchased module | AI-assisted integration | |
|---|---|---|
| Validation scope | defined by the vendor, often a multiple of the functionality actually used | limited to the actual use case |
| Triggers for regression testing | releases of the core system and of the module vendor; for cloud solutions, timing set by others | releases of the core system and own dependencies; with a public cloud core, also set by others |
| Supplier qualification | audit, questionnaire, annual assessment | not applicable; the existing in-house development process applies |
| Specification | derived from vendor documentation | created anyway as the basis for development; it must be approved as a requirements specification |
| Risk | discontinuation, pricing policy, roadmap | dependency on individuals, maintenance discipline |
The lever, then, is not the development time saved but the small, predictable validation scope that you define yourself. With AI-assisted generation of test cases and evidence, an interface with 200 lines of code and twelve test cases can, in our experience, be validated in around two days. Done manually, it takes weeks. A purchased module brings functionality nobody asked for, yet still goes through a cycle of risk assessment and revalidation.
Two risks come with this, in order of relevance:
- Maintenance debt. Code is written in hours but lives for ten years. Without a designated owner for each component, you end up with a code base nobody understands any more. It takes the discipline to inventory solutions, document them and assign responsibilities to roles rather than to individuals.
- Inspector perception. In-house GxP software is permitted but attracts attention. A clean specification, risk assessment and test evidence, in the same form as for standard software, defuses this point.
The regulatory framework is moving in the same direction but is not yet settled. The new EU GMP Annex 22 on artificial intelligence has been available as a draft since the consultation of 7 July 2025 and is not yet in force. The revision is ongoing; whether the original exclusion of generative models will be dropped after the EMA workshop at the end of June 2026 remains open but is under discussion. Annex 22 replaces neither Annex 11 nor Chapter 4; it supplements them. Anyone designing systems and applications today should not wait for a date but build on the principles that have remained stable across all drafts: defined intended use, risk-based testing and human decision-making at critical steps.
What follows from this
The ERP system remains standard software. For extensions whose development effort can now be estimated in-house, however, licence costs deserve critical scrutiny.
Three steps:
- Sort your existing portfolio by gaps. Which modules, connectors and additional licences cover a function that is smaller than its price? A cost-benefit assessment, not a project.
- Check addressability before anything is designed. A system whose business functions can only be reached through screens remains closed, no matter how good the tools become. For new procurements, this is a tougher selection criterion than any feature list.
- Define the validation path before the first prompt. Requirement, risk assessment, test cases against the requirement, a named owner, an entry in the system inventory. Anyone who deals with this afterwards ends up working in a non-validated system.
Recommendation: capture your processes and requirements and implement a validated pilot on a functionally small interface, such as a connector, a reporting export or a format converter. Not as a pilot for the technology, which works. As a pilot for the validation path, because that is the real bottleneck.
Standard software keeps its place, above all in the ERP core. At the edges, however, the decision criteria are shifting in favour of custom software: AI reduces the effort for development, validation and maintenance to the point where a tailored solution pays off more often than a purchased module. Increasingly, it can be implemented by the business analyst, who combines process knowledge with IT understanding and no longer just writes specifications. The premium for closed systems can no longer be enforced.
Why Significon
The cost comparison above assumes that three competencies are held by one party: business process knowledge, accountability for validation and solution design. If these roles are split across three service providers, the coordination effort eats up the cost advantage. A common outcome is an interface that works technically but is not released by Quality Assurance.
We cover all three roles under one roof. Significon AG works in SAP landscapes at pharmaceutical, medical device and chemical companies, where GxP environments are part of everyday business. Our consultants design your process with you, then implement it and carry out validation in line with your local QA requirements.
Our offering comprises three building blocks:
- Process and requirements capture. Together with your business departments, we capture the process, the requirements and the GxP relevance of the interfaces and extensions around your ERP. The result is a prioritised list of candidates with effort estimates.
- Pilot on a manageable interface. From the requirements specification through risk assessment and test evidence to handover into your operations. The pilot shows whether the validation path holds and provides actual figures for comparison with a purchased module.
- Target architecture. Process modelling in BPMN, execution in the automation layer, data held in the system of record, with no redundant status management.
If the pilot shows that a purchased module is more cost-effective, we will tell you. We do not recommend a project that does not pay off.
Get in touch: together with you, we capture processes and requirements and build on them to implement a validated pilot. You then have a sound basis for deciding between in-house development and a module. At Significon, SAP process knowledge, GxP validation experience and solution architecture come together in one team.
SAP, SAP S/4HANA and SAP Business Technology Platform are trademarks or registered trademarks of SAP SE or its affiliates in Germany and other countries. Adobe, Photoshop, Illustrator and Premiere are trademarks or registered trademarks of Adobe Inc. in the United States and/or other countries. All other product and company names mentioned are trademarks of their respective owners.
