Blog
AI as a building material, not an add-on
Most AI integrations look the same from the inside: a finished application with a chat window bolted onto it. The model gets read access to part of the data and answers questions. It demos well. Three months later nobody opens it. The reason is structural: the AI arrived after every important decision had been made.
In construction, the material decides the structure. Steel allows spans that timber does not. Nobody draws a building first and picks the material afterwards. AI works the same way. If you know at drawing stage that a language model can classify, search by meaning and extract data, you draw a different architecture — not the same one with an extra screen.
Where should a company start with AI?
With one process where a person currently reads, sorts or retypes data. Not with a model or a vendor. First check whether the outcome can be written as a hard rule. If it can, write the rule. If it cannot, because the input is human text or a document in an arbitrary layout, you have a candidate for AI.
The second step is arithmetic: volume, minutes per pass, cost of a mistake. A task done three times a week rarely repays the build and the upkeep; hundreds of times a day repays them quickly, even at accuracy well below perfect.
The third step is architectural and usually skipped. Decide where the context handed to the model lives, where you store its decision with the reasoning, and what happens when the model answers badly. All three change your database schema.
AI as material or AI as an add-on: what actually differs?
The moment of the decision. A material is chosen before the drawing and shapes the data model, the cost and the maintenance. An add-on is fitted after handover, so it must fit whatever already stands. The difference is invisible at the demo and obvious in year two, when something has to change.
| Criterion | AI as material | AI as add-on |
|---|---|---|
| Decision point | Architecture stage, before the schema | After go-live, as a separate module |
| Data and context | Data model with room for context, history and embeddings | Context stitched from whatever the API returns |
| Cost | Budgeted: token ceiling per operation, caching, model sized to the task | Per-request billing that grows linearly with traffic |
| Auditability | Every decision logged with input, prompt version and output | No trace; two weeks later nobody can explain an answer |
| Failure mode | A model-free path built into the process: rule, queue, human | Vendor outage stops the feature |
| Maintenance | A model swap is a layer change plus regression tests on collected cases | A model swap means rewriting the module and checking by hand |
Which parts of the architecture change?
Four, and they exist in almost every business system. In each case the model does not add a screen — it removes a layer of code you would otherwise maintain for years.
- Classification and routing instead of a rule tree. A growing list of keyword conditions becomes a category table with examples, a confidence threshold, a decision log and a path for uncertain cases.
- Semantic search instead of filters. Filters require the user to know the data structure; meaning-based search requires the system to know the content. That means embeddings, a vector index and a job that recomputes them on every change — storage layer, not UI.
- Document extraction instead of forms. The form stops being the entry point and becomes a verification screen: the original document enters the system, extracted fields carry a needs confirmation status, the UI shows each value next to its source. Different permissions, different data model.
- Variant generation instead of templates. Generation needs constraints, versioning and approval before publication: content stops being a file and becomes a process with history.
What breaks when AI is added at the end?
Four things, always the same. None shows up in the demo week; all hurt after a few months in production.
- Nowhere to keep context. If the schema was not designed for it, context is assembled ad hoc from several queries and answer quality becomes random.
- No decision log. Without input, prompt version and output stored together, you cannot show why a case was classified the way it was. That is an audit problem, not only an engineering one.
- No fallback. Provider outage, rate limit, malformed response — with no alternative path the feature simply stops.
- Cost is a variable, not a parameter. Designed-in AI has a token budget per operation, a cache for repeated queries and a smaller model where a large one is not needed.
When is AI the wrong material?
More often than conference slides suggest. Language models are good at fuzzy tasks and expensive at exact ones. Skip AI when the rule is deterministic (rates, validation, unit conversion), when every decision must be reproducible to the character, when volume is too low to repay the build, or when there is no data to build a test set from — without one you cannot tell whether a model change improved anything.
How we make this call in our own products
In each of our four products, the question where AI, where ordinary code is answered at the architecture stage. The line runs where the data stops being unambiguous.
In BARVEA, our BIM and common data environment, IFC quality checks split in two. The hard checks — does the attribute exist, is the status within S0–S6, does the file meet ISO 19650 requirements — stay ordinary code, because the result must be reproducible. The soft part starts with names and descriptions written by people, where the same thing gets called several ways. That is where a language layer helps, and where the data model must reserve room for a needs human review state.
In ClimaBox, an IoT device with a live dashboard, raw temperature, humidity and CO₂ readings are number series. Alarm thresholds stay rules: they must fire immediately and locally. Interpreting what the readings mean together is a job for the language layer. We separated the two before writing the dashboard, so the alarm has to work whether or not the descriptive layer is there.
We are a young company, so our own products are the evidence — see projects. We do not do body leasing, hosting without a project, or template websites: we take the problem, design the structure and build it. Scope is on the services page. To find out whether AI is material or add-on in your process, describe it on the contact page. A quote usually comes back within one working day.