Why Enterprise AI Is Bringing Software Vendors Back Into The Building
Enterprise software spent years moving in the opposite direction. Products became cloud services, implementation was standardised, support moved online and the supplier’s physical presence at the client became less important. Generative AI is now reversing part of that development.
Companies can activate an AI assistant within minutes, but connecting a model to the processes that determine how a bank handles an exception, how an insurer assesses a case or how a manufacturer coordinates an order is a different undertaking. The software may arrive through the cloud; the difficult work begins inside the organisation.
That is why some enterprise technology companies are expanding teams of engineers who work directly with clients. The role is often described as forward-deployed engineering: developers are placed close to the business, where they can examine workflows, connect systems and turn a general-purpose product into something that works within a specific operating environment.
Camunda, the Berlin-based process-automation company, is one example. Its software coordinates workflows for organisations ranging from banks and industrial groups to the US space agency NASA. As clients try to introduce AI into these processes, Camunda is increasing the number of engineers who work with them directly. The commercial proposition is no longer confined to a software licence. It increasingly includes the capacity to understand how the client’s business actually functions.
An AI model does not understand the company around it
The attraction of generative AI lies partly in its apparent universality. The same model can draft an email, summarise a report, answer a technical question or classify a document. This versatility can create the impression that deployment is mainly a matter of choosing a provider and connecting an interface.
Corporate processes are less accommodating.
A loan application may pass through several systems, departments and approval thresholds. An insurance claim can be processed automatically until it contains an unusual combination of circumstances. An incoming document may need to be classified, checked against existing records and routed to a specialist team. Each step carries its own permissions, dependencies and consequences.
A language model sees only the information and tools made available to it. It does not inherently know which system contains the authoritative record, when an employee must approve a decision, what constitutes an exception or which action would violate an internal control.
These details often live outside formal process documentation. They are distributed among legacy applications, departmental rules, spreadsheets and the experience of employees who know how work is completed when the standard route fails. A vendor cannot discover that structure from a remote demonstration.
The engineer working inside the client organisation is therefore not simply installing an AI feature. The more valuable task is reconstructing the process around it.
Legacy systems are becoming part of the AI project
Most established companies are not building their AI architecture on a blank page. They already operate complex combinations of enterprise resource planning software, customer relationship platforms, document-management systems, databases and specialist applications accumulated over many years.
AI must work across this environment without compromising the systems that continue to hold essential data and execute core transactions.
This makes orchestration more important than the model itself. A model may interpret an unstructured request, but another layer still has to determine which systems should be consulted, which rules apply and what should happen next. The process must also remain visible enough for the company to understand how a result was produced.
Camunda’s work with financial institutions illustrates the principle. In one banking process, incoming correspondence is classified and directed to the relevant department, while an AI agent deals with more complicated exceptions. The agent operates within a traceable workflow rather than acting as an independent black box. Its individual steps can be followed and controls can intervene before an error affects the client or the wider process.
This type of deployment is far removed from adding a chatbot to an existing application. It requires a detailed view of the operating model, including the systems that were never designed to work with generative AI.
The process must be redesigned, not decorated
Many early corporate AI projects added a new interface to an unchanged workflow. Employees received a writing assistant, a search field or a summarisation tool, while the structure beneath it remained intact.
Such applications can save time, but they rarely produce the larger productivity gains associated with automation. An employee may generate a document more quickly and still have to transfer the information manually, verify it in another system and request approval through an established sequence of emails.
The more consequential use of AI begins when companies reconsider the process itself. Which steps require human judgement? Which checks can be automated? Where should a model interpret unstructured information, and where should deterministic software remain in control? What should happen when the model lacks confidence or encounters a case outside its mandate?
Answering these questions requires operational knowledge as much as technical skill. Software vendors that once concentrated on product configuration are consequently moving closer to consulting, process design and organisational change.
The distinction between a software company and an implementation partner becomes harder to maintain when the product’s value depends on how deeply it is embedded in the client’s operations.
Different tasks call for different models
The presence of vendors inside the company is also driven by a more fragmented model market. Enterprises are no longer assuming that every AI task should be sent to the largest and most expensive system available.
A powerful frontier model may be justified when the task requires complex reasoning or involves ambiguous material. A smaller model may be sufficient for document classification, information extraction or repetitive internal queries. Companies may also prefer a European or open-weight model for applications where sovereignty, deployment control or data location carries greater weight.
The challenge lies in assigning the right model to each task.
This is partly a technical decision and partly an economic one. AI costs can rise quickly when large models are used indiscriminately across high-volume processes. The most sophisticated option may add little value to a routine classification task, while a cheaper model could perform reliably within a tightly defined workflow.
The emerging enterprise architecture therefore resembles a routing system. Each request is assessed according to sensitivity, complexity, cost and required performance before being directed to an appropriate model. Some tasks may remain within the company’s controlled infrastructure, while others are sent to external services.
Designing and maintaining that system requires a detailed understanding of the client’s workload. A vendor selling access to a single model can remain at a distance. A supplier responsible for coordinating several models across core processes cannot.
AI introduces a different standard of accountability
Traditional process automation is generally predictable. A rule-based system follows predefined instructions and produces the same outcome when it receives the same input.
Generative models behave differently. They can interpret ambiguous material and manage cases that rigid software cannot handle, but their outputs are probabilistic. They may misunderstand a document, invent information or choose an inappropriate action.
Companies cannot remove this risk simply by selecting a reputable provider. They have to build controls around the model.
Those controls may include confidence thresholds, pre-approved tool access, restricted data sources, human review and automatic escalation. The system should record which model was used, which information it received and which steps followed from its response. When the process affects a client, employee or regulated decision, the organisation must be able to reconstruct what happened.
This is one reason process-automation vendors may gain influence in the enterprise AI market. Their value lies less in producing another model than in placing models inside governed workflows where their authority is limited and their actions remain observable.
The vendor’s role becomes closer to that of an engineer responsible for a functioning operational system. A failed demonstration is inconvenient. A failed production process can interrupt payments, delay orders or create regulatory exposure.
Swiss companies will expect proximity without surrendering control
The shift is especially relevant in Switzerland, where many companies combine internationally distributed operations with demanding expectations around confidentiality, auditability and operational resilience.
Banks, insurers, pharmaceutical groups and industrial companies may be willing to use external AI technology, but they need clarity over where data flows, which models are involved and how decisions are controlled. Some will require deployment within a private cloud or their own infrastructure. Others will combine external and internally operated models according to the sensitivity of the task.
A vendor’s ability to support several models can therefore become more valuable than exclusive access to one. Companies may want to use systems from major US providers alongside European models or open-weight alternatives. They will also want the freedom to replace a model when its cost, performance or risk profile changes.
That flexibility is only useful when the surrounding workflow has been designed accordingly. If every connection, control and data pipeline is built around one provider, apparent choice disappears. Vendor independence must be engineered into the architecture from the beginning.
The supplier working closely with the client is well placed to do this, but proximity also creates a new procurement concern. A company can reduce dependence on a model provider while becoming heavily reliant on the implementation vendor that understands its processes and maintains the orchestration layer.
Contracts, documentation and internal capability therefore matter. The organisation should retain access to its process definitions, evaluation data, integration logic and operating documentation. Engineers from the vendor may help build the system, but the client must remain capable of understanding what has been built.
Forward-deployed engineers are becoming part of the product
The renewed demand for engineers on site does not mean enterprise software is returning to the era of large, permanent implementation teams. The commercial logic is more selective.
AI products are relatively general at the point of sale. Their value increases when they are applied to a narrow process with clear data, rules and outcomes. Forward-deployed engineers shorten the distance between the generic capability and the working application.
They can identify an initial process, build the integrations, establish performance tests and resolve the problems that emerge only in production. Once the architecture is stable, the company can extend it to related workflows with less direct assistance.
For the vendor, this approach offers a way to secure adoption beyond the pilot stage. It also provides information that cannot be gathered through conventional product analytics. Engineers see where the software fails, which controls clients require and how real operating environments differ from the assumptions made by product teams.
The arrangement is expensive, which means it will not suit every client or every application. Yet vendors may accept that cost when the alternative is a series of promising pilots that never become operational systems.
Software is becoming inseparable from implementation
The enterprise software industry spent decades trying to make products more repeatable. Standardisation supported higher margins, faster sales and easier international expansion. AI complicates that model because the technology derives much of its value from context.
A general model can be sold repeatedly. A functioning enterprise AI system depends on the client’s data, process architecture, controls and organisational responsibilities. The closer the application comes to the company’s core operations, the more difficult it becomes to separate the product from the work required to implement it.
This does not turn every software provider into a traditional consultancy. The stronger vendors will still rely on reusable platforms, standard connectors and common governance components. Their engineers will not rebuild every system from the beginning.
They will, however, need to understand the organisation in far greater detail than a conventional software subscription requires.
Enterprise AI is bringing vendors back into the building because companies have discovered that model access is the easy part. The commercially valuable work lies in deciding what the model may do, connecting it to the systems that matter and ensuring that the resulting process remains economical, observable and under control.
