AI and systems
Building AI Into an Existing Business System Without Replacing It
In short
The way to add intelligence to systems a business already runs is to sit downstream of them and never write back. Your accounting package keeps owning the books. Your ERP keeps owning orders. The intelligence layer reads from them, computes governed metrics, and reasons over the result. The moment it starts writing back, you have taken on the operational risk of every system it touches, and adoption stops being incremental.
That single boundary decision determines almost everything else about the build.
Why read-only is the load-bearing decision#
A business can adopt a read-only layer on a Tuesday and turn it off on a Wednesday with nothing lost. That is what makes it possible to sell to a company that will not tolerate a migration.
It also constrains the failure mode usefully. A read-only system that is wrong produces a bad answer. A write-capable system that is wrong produces a bad answer and a corrupted ledger.
The temptation to write back arrives early and always sounds reasonable. It usually presents as a small convenience, updating a status or creating a record. Hold the line until the value of writing clearly exceeds the risk of owning the source system's integrity, and treat crossing it as a deliberate decision with its own approval rather than a feature.
Six architectural decisions to make before the first line of code#
1. The application reads views, not tables
Define a set of metric views and have the application read only from those. Raw tables, sync jobs and upload flows stay owned by the pipeline and are never queried directly.
This one boundary is what lets the pipeline change without breaking the front end, lets a second client be added without touching application code, and makes a metric definition auditable because there is exactly one place it is defined.
2. Multi-tenancy is a constraint, not a feature
Put a tenant identifier on every table from the first migration and enforce isolation at the database level rather than in application code, so an application bug cannot bypass it.
The reason is timing rather than security. This cannot be retrofitted once data exists. It is nearly free on day one and close to a rewrite later.
3. Build against a synthetic twin
Maintain a dataset with schemas identical to production and have developers build exclusively against it, so nobody working on the system has access to real figures.
This is the cleanest answer to the objection that stops most small firms from ever being handed a client's financial data. Identical schemas mean the synthetic set is not a toy, and the access answer becomes structural rather than a matter of trust.
4. Isolation is absolute, visibility is graduated
Two different problems, commonly conflated. Isolation between clients is a structural guarantee that is never negotiable. Visibility within a client is a permissions question that will keep changing as the business grows, so design it configurable from the start.
5. Deterministic where correctness matters, model where judgement matters
Do not let the model produce values that must be provably right. A query or a solver computes the figure. The model interprets, explains and evaluates.
In one system generating architectural layouts, a constraint solver computes every coordinate and the model only expresses design intent as structured relationships, because a model asked to produce geometry produces plausible geometry that is frequently invalid. The same division applies to a revenue number or an inventory position.
6. Never execute the user's words
Convert natural language into a structured object and validate it against a schema before anything downstream runs. Raw text is never executed as code and never passed directly to an API.
This is most of the prompt injection defence for a business system, and it is architectural rather than clever.
Sequencing that avoids the usual failure#
Prerequisites are not sprint one. Environment isolation and a deployment pipeline are completed before feature work begins, not scheduled as early tasks. Anything in sprint one gets traded away under pressure. A prerequisite does not. On one project the shared database between development and production was named explicitly as the most dangerous condition in the setup, and closing it came before anything else.
Do not put the AI layer over incomplete data. An agent reasoning over a partial picture produces confident output about a partial picture, which is worse than no output because it is not visibly partial. Integrate every data source first, then add the intelligence layer. On one platform this also meant holding the financial views back separately until an accountant had reviewed them.
Spike load-bearing dependencies with a costed fallback. Before writing production code against a third-party component, run a short spike with explicit pass criteria and a required go or no-go decision. Name the fallback and what it costs in advance. On one build the fallback path was two to three months against two to three weeks for the integration, which made the decision bounded rather than open-ended.
Build integration, not infrastructure. The failure mode for small teams is building the impressive-sounding component that already exists as a library, and under-building the boring glue that is actually the product.
Reuse the infrastructure you already run. Where an organisation already operates a warehouse or an AI platform for another project, use it. The saving is not only cost, it is one fewer thing to operate and one fewer access model to maintain.
What this looks like in practice#
A typical shape: connectors pull from the source systems on a schedule into a warehouse. Versioned views define the metrics. An API serves those views with provenance, freshness and coverage attached to every figure. The interface renders them, and the intelligence layer reasons over the same views a human would query.
Nothing in that chain writes to the source systems. Every layer can be replaced without touching the others. And a second client is a configuration change plus new connectors, not a fork of the codebase.
Common questions#
Will this work if our systems are old or have no API? Usually. Scheduled exports, database replicas and file drops all work as sources. It is slower and less pleasant than an API and it does not change the architecture.
How long before it is useful? A first vertical slice on one domain with real data is typically weeks rather than months, provided the source access is granted promptly. Access is almost always the critical path, not the build.
Does the AI need to be in version one? No, and it usually should not be. Governed metrics with visible provenance are valuable on their own, and they are the prerequisite for the intelligence layer being trustworthy.
What about data the system cannot see? Show it as unavailable rather than estimating it. Withholding is cheap. Recovering credibility after a fabricated figure is not.
When is writing back justified? When the value clearly exceeds taking on the source system's operational risk, and as a deliberate decision with its own approval. Not as a convenience feature.