Applied AI in business: agents, document intelligence, content systems

Framing

Why applied AI is a different problem now

Applied AI in business used to be a research project. A team would identify a use case, hire specialists, build a model, integrate it, and run a pilot. The result, when it worked, was a custom system that the team understood and the rest of the organisation did not. The result, when it did not, was a sunk cost that the organisation wrote off and tried again.

That model is finished. The technology that replaces it is the four-layer applied AI stack: Experience (where people meet the system), Orchestration (how work moves through it), Intelligence (which models think, selected for quality, language, speed, cost, and control), and Infrastructure (where it runs — managed cloud, private cloud, or self-hosted). We deliver applied AI on this architecture, in up to 12 languages, across 8 service lines, with the same engineering standards as the rest of the connected ecosystem.

The 8 service lines are: AI agents, chatbots and copilots, workflow automation, private knowledge AI, voice and call assistants, document intelligence, content systems, and AI advisory. Each is a real practice, not a brochure entry. Each is delivered on the same architecture. Each connects to the rest of the connected ecosystem: the website, the email, the document store, the CRM, the help desk, the ERP, the APIs.

The engineering principles are six: data minimisation, explicit access, human checkpoints, deployment choice (managed, private, self-hosted, open models — pragmatic), traceable work, and cost boundaries. These are not slogans. They are the architectural commitments that the platform is built on, the ones a buyer can verify by reading the documentation and inspecting the deployment.

This article sets out the architecture, the operating model, and the economics of applied AI. It is written for organisations that have lived through the research-project problem and are ready for the production architecture.

The shift to production architecture for AI is the same shift that cloud computing made a decade ago: the move from custom-built, on-premise, one-off implementations to standardised, multi-tenant, operationally mature platforms. The research project is the custom build. The production architecture is the standardised platform. The custom build has its place, but the standardised platform is what scales, and the standardised platform is what organisations of every size can afford.

The AI capability is also the test of whether the connected ecosystem is actually connected. An AI service that does not integrate with the rest of the platform is a separate product. An AI service that integrates with the website, the email, the document store, the CRM, the help desk, the ERP, the APIs, the hosting, the voice, the eSIM, and the cybersecurity practice is a layer in an architecture. The connected ecosystem delivers the AI as a layer, and the layer is the difference between a feature and a capability.

Architecture

The four-layer model and what is inspectable

The four-layer model is the architecture of every applied AI engagement. The Experience layer is where people meet the system: a website chat, a team copilot, a phone assistant, a private portal, an inbox integration, or a background workflow. The Orchestration layer is how work moves through the system: agents, tools, rules, memory, hand-offs, budgets, human approval points. The Intelligence layer is which models think: commercial or open, selected for the use case on quality, language, speed, cost, and control. The Infrastructure layer is where it runs: managed cloud, private cloud, or self-hosted.

Each layer is replaceable. The buyer can change the experience without changing the orchestration. The buyer can change the orchestration without changing the model. The buyer can change the model without changing the infrastructure. The buyer can change the infrastructure without losing the work. This is the architectural property that makes the platform an ecosystem and not a product.

The 8 service lines map to the architecture. AI agents operate in the Orchestration layer, using tools, calling APIs, hand-ing-off to humans at sensitive steps. Chatbots and copilots sit in the Experience layer, with the model and the orchestration below. Workflow automation is the connective tissue, moving data between systems and triggering actions. Private knowledge AI is a layer on top of the customer's own documents, with explicit access controls. Voice and call assistants are a layer on top of the voice platform. Document intelligence extracts, classifies, compares, and drafts from PDFs, forms, invoices, and knowledge bases. Content systems research, plan, and adapt content across channels. AI advisory is the human-led practice that scopes the use case, selects the architecture, and guides the rollout.

The architecture is inspectable. The buyer can audit the configuration, see which models are running, see the data flow, see the human approval points, see the cost. The buyer can change any layer without re-implementing the rest. The buyer can take the configuration and run it on a different infrastructure, with a different model, on a different experience surface.

The platform is published in up to 12 languages: EN, DE, FR, ES, IT, PT, NL, PL, CS, SV, DA, RO. The legal text is in the user's preferred language. The commercial terms are in the user's preferred currency. The delivery is in the user's preferred timezone. The platform is international by design, not by retrofit.

The four-layer model is a separation-of-concerns architecture, and the separation is the property that makes the platform replaceable at every layer. The buyer can change the experience surface (a website chat becomes a mobile app, a mobile app becomes a voice assistant) without changing the orchestration. The buyer can change the orchestration (a single-agent workflow becomes a multi-agent system) without changing the model. The buyer can change the model (a commercial model becomes an open model) without changing the infrastructure. The buyer can change the infrastructure (managed cloud becomes private cloud) without changing the work. This is the property that the research-project model does not have: the property of independent replacement at every layer.

The eight service lines are not a product catalogue. They are a coverage map of the AI capability space. The buyer does not buy a chatbot; the buyer buys the chatbot capability, the document intelligence capability, the workflow automation capability, and so on, each as a layer in the same architecture. The buyer can start with one capability, expand to others, and replace any capability without losing the rest. The coverage map is the architectural commitment, and the architectural commitment is the buyer's right to evolve.

Operating model

Discover, Design, Prototype, Integrate, Improve

Applied AI is delivered in five stages. Discover maps the outcome, the people, the data, the risks, and the repetitive work — before any model or platform is chosen. Design defines the assistant, the workflow, the knowledge sources, the integrations, and the approval points. Prototype builds a focused working version and tests it with realistic inputs. Integrate connects the system to the tools that already shape how work happens. Improve monitors quality, cost, and adoption, and updates the system as the work changes.

Discover is the most important stage. The output is a written document the buyer can audit. The document maps the existing work, the people, the data, the systems, the regulatory boundaries, the repetitive tasks, and the highest-value opportunities. Nothing about the existing systems changes during Discover. The goal is to understand before changing.

Design produces a focused working version: a single assistant, a single workflow, a single knowledge source, a single set of integrations, a single set of approval points. The design is documented. The decision is documented. The buyer's existing systems are not replaced on day one; they are augmented.

Prototype produces a working version the buyer can use in production for the first deliverable. The deliverable might be a single customer-facing service, a single internal process, or a single compliance workflow. The point is that the working version is real, that it uses the buyer's real data with the buyer's real identity, and that it can be evaluated against the buyer's real metrics.

Integrate connects the working version to the tools the buyer already uses: email, document store, calendar, CRM, help desk, ERP, ticketing. Each integration is documented, reversible, and has a human approval point. Improve is the operating phase: monitoring, documentation, human approval, cost tracking, adoption measurement, and continuous improvement.

The five-stage delivery process is not a methodology imposed on the buyer. It is the operational pattern that emerges from the architecture, and the pattern is the same regardless of the use case. Discover maps the work, the people, the data, the risks, and the repetitive tasks. Design defines the assistant, the workflow, the knowledge sources, the integrations, and the approval points. Prototype builds a working version against realistic inputs. Integrate connects the working version to the tools the buyer already uses. Improve monitors quality, cost, and adoption, and updates the system as the work changes. The pattern is the operational discipline that turns the four-layer architecture into a production system.

The human checkpoints are the property that makes the AI capability safe to deploy. The model is given access only to the data it needs. The model is required to surface its sources. The model is required to escalate to a human at any sensitive step. The model is not allowed to take an action with a defined cost boundary without approval. The human checkpoints are documented, audited, and reviewed. The checkpoints are not a limitation; they are the architectural property that makes the AI capability trustworthy for the buyer.

Economics

The case for production architecture over research project

The economic case for production applied AI is the difference between a system that runs and a system that demos. A research project produces a one-off artifact, with a custom model, a custom integration, and a custom support model. The artifact is not reusable, the model is not maintainable, the integration is not portable. The total cost of ownership is the initial project plus the ongoing maintenance plus the eventual replacement.

A production architecture produces a system that the buyer can audit, replicate, evolve, and ultimately own. The four-layer model means that each layer is replaceable. The engineering principles mean that the system is inspectable. The deployment choice means that the system is portable. The total cost of ownership is the initial project plus the ongoing operation, with the cost of evolution amortised across the architecture rather than concentrated in any single component.

The per-engagement cost is scoped to the use case. There is no per-seat licence, no bundled opaque pricing. The buyer knows what is being built, what it costs to build, what it costs to run, what it costs to evolve. The pricing is published, not hidden behind a contact form.

The economic case compounds over time. A research project has an economic life of one or two iterations, after which it is replaced. A production architecture has an economic life measured in years, with each year's improvement building on the last. The architecture is the difference. The architecture is the savings.

The economic case for production AI is the difference between a system that runs and a system that demos. A research project demos well and runs poorly. A production architecture runs well and demos well, because the production architecture is the demo. The buyer does not need a separate proof of concept; the production deployment is the proof of concept. The economic saving is the cost of the proof of concept that the buyer does not need to build, and the saving is recurring, because every future use case starts with the production architecture, not with a new research project.

The per-engagement cost is the cost of the work, not the cost of a per-seat licence. The buyer pays for the design, the prototype, the integration, and the improvement, and the cost is scoped to the use case. There is no bundled per-seat pricing, no opaque tier structure, no hidden escalation. The cost is published, the scope is documented, and the success criteria are agreed before the first engagement. The cost model is the architectural model: transparent, inspectable, and aligned with the buyer's outcome.

Risk

Architectural questions, not sales claims

The risk of applied AI is hallucination — the model generating plausible but incorrect output. The mitigation is explicit access controls, human checkpoints, traceable work, and cost boundaries. The model is given access only to the data it needs. The model is required to surface its sources. The model is required to escalate to a human at any sensitive step. The model is not allowed to take an action with a defined cost boundary without approval.

The risk of data leakage is the model sending data to a third party without the buyer's knowledge. The mitigation is deployment choice: managed cloud, private cloud, or self-hosted. The buyer chooses where the data lives. The buyer chooses which models run. The buyer chooses whether the data ever leaves the buyer's infrastructure.

The risk of lock-in is the buyer becoming dependent on a specific model, a specific vendor, a specific platform. The mitigation is the four-layer model: each layer is replaceable, the configuration is portable, the data is exportable, the architecture is open. A buyer who chooses to leave can take the configuration, the data, and the integrations, and run the system on a different platform.

The risk of cost overrun is uncontrolled model usage. The mitigation is cost boundaries: per-engagement, per-workflow, per-request budgets, with alerts and kill-switches. The buyer sees the cost in real time. The buyer sets the boundaries. The buyer pays for what is used, within the boundaries they set.

The architectural questions a buyer should ask are these. Can I see which model is running? Can I see where the data lives? Can I export my configuration? Can I leave without losing the work? The answer to all four is yes.

There is a fifth risk worth naming: the risk of data drift. The data the model is trained on changes over time, and the change can erode the model's accuracy without the change being visible to the user. The mitigation is continuous monitoring with defined quality metrics, periodic re-evaluation against real inputs, and a documented escalation chain when drift is detected. The platform is built to surface drift before it becomes an incident, and the surfacing is part of the operating model, not a separate service.

There is a sixth risk worth naming: the risk of a model that is no longer available. A commercial model can be deprecated by the provider, and a deprecated model forces a migration. The mitigation is the deployment choice: the buyer can use an open model, deploy it on private infrastructure, and own the model lifecycle. The buyer is not bound to a single model provider, and the buyer can switch models without changing the rest of the architecture. The portability is the property that protects the buyer from the provider's deprecation decisions.

Implementation

A week-by-week sequence

Week 1-3: Discover. We map the outcome, the people, the data, the risks, the repetitive work. The output is a written document the buyer can audit.

Week 4-6: Design. We define the assistant, the workflow, the knowledge sources, the integrations, the approval points. The design is documented and inspectable.

Week 7-10: Prototype. We build a focused working version and test it with realistic inputs. The prototype uses the buyer's real data with the buyer's real identity.

Week 11-14: Integrate. We connect the working version to the tools the buyer already uses. Each integration is documented, reversible, and has a human approval point.

Week 15 and beyond: Improve. The system is live. The monitoring is active. The cost is tracked. The human approval points are exercised. The system is updated as the work changes.

The sequence is not rigid. A buyer can start with a single use case, validate the architecture, and expand. The platform is designed for incremental adoption, not for a forced all-at-once deployment.

The implementation sequence is designed to deliver value early. The first three weeks (Discover) produce a written document that the buyer can audit. The document maps the work, the people, the data, the systems, the regulatory boundaries, and the highest-value opportunities. The document is not a sales artefact; it is the buyer's own analysis, and the buyer can take it to a different provider, validate it against a different methodology, or use it as the basis for a procurement process. The document is the buyer's first deliverable.

The remaining weeks (Design, Prototype, Integrate, Improve) build the system in stages, with each stage producing a working artefact the buyer can evaluate. Design produces the architecture. Prototype produces a focused working version tested with realistic inputs. Integrate connects the working version to the tools the buyer already uses. Improve monitors quality, cost, and adoption, and updates the system as the work changes. Each stage is a milestone, each milestone is a decision point, and each decision point is the buyer's, not the provider's.

FAQ

Five plain-language questions

Which model will run my AI? The model is selected for the use case on quality, language, speed, cost, and control. Commercial and open models are both options. The choice is part of the design, not a strategic commitment.

Where does my data live? You choose: managed cloud, private cloud, or self-hosted. The data stays in the infrastructure you select. The data does not leave the infrastructure you select unless you explicitly direct it to.

How do you prevent hallucination? Explicit access controls, human checkpoints, traceable work, cost boundaries. The model is given access only to the data it needs. The model is required to surface its sources. The model escalates to a human at sensitive steps.

Can I leave the platform? Yes. The four-layer model means each layer is replaceable. The configuration is portable. The data is exportable. You can take the work and run it on a different platform.

How does pricing work? Per engagement, scoped to the use case. There is no per-seat licence, no bundled opaque pricing. The buyer knows what is being built, what it costs to build, what it costs to run, what it costs to evolve.

For organisations that have not yet adopted production AI, the most common question is about the first use case. The first use case is the one that produces the most value with the least risk. It is usually a contained workflow with a clear input, a clear output, and a clear success metric. Document intelligence is a common first use case. Workflow automation is another. Customer service automation is another. The first use case is not a platform; it is a proof of the architecture, and the architecture is what scales to the rest.

For organisations that have already adopted production AI, the most common question is about the next use case. The next use case is informed by the first: what worked, what did not, what the team learned, what the data showed. The platform is the same; the use case is different. The buyer can start with document intelligence and move to customer service automation, with the same architecture, the same team, the same support model, and the same option to leave. The platform is the constant; the use case is the variable.

Worked example

A concrete case with numbers

Consider a mid-sized legal practice with 40 fee earners, processing approximately 1,200 contracts per year. The current process is manual: a paralegal reads each contract, identifies the key clauses, summarises the terms, and enters the data into the practice management system. The process takes approximately 90 minutes per contract, with a peak of 4 hours for complex agreements. The annual cost in paralegal time is approximately EUR 270,000.

Under an applied AI engagement, Discover maps the contract types, the key clauses, the data fields, the existing systems, and the regulatory boundaries. Design defines a document intelligence assistant that extracts the key clauses, classifies the contract type, and populates the practice management system. Prototype builds a working version that handles the 12 most common contract types with 92% accuracy and a human review step for the remaining 8%. Integrate connects the assistant to the document store, the practice management system, and the email system. The system goes live.

The annual paralegal time drops from approximately EUR 270,000 to approximately EUR 90,000, with the remaining time spent on the human review step and the complex agreements. The annual run-rate cost of the AI system, including infrastructure, models, and support, is approximately EUR 36,000. The net annual saving is approximately EUR 144,000. The payback period is approximately 4 months.

The trust argument is not the saving alone. It is the architecture: the practice can audit the model's behaviour, change the model, change the infrastructure, and leave the platform at any time. The configuration is portable. The data is exportable. The system is the practice's, not the vendor's. The applied AI is one layer in a connected ecosystem that includes hosting, voice, eSIM, and cybersecurity. The vendor-stack problem is gone for AI too.

The numbers are illustrative, not a quote. Every use case is different. The principle holds: applied AI, delivered on a production architecture with human checkpoints, deployment choice, and the option to leave, costs less in total than manual processing — and produces more consistent, more auditable, more scalable work.

Consider a second worked example: a 500-person financial services firm with a customer service team of 80 people handling 4,000 customer enquiries per day. The current process is a manual triage workflow: an agent reads the enquiry, classifies it, routes it to the right specialist, and follows up. The average handling time is 18 minutes per enquiry, and the team is at capacity. The annual cost in agent time is approximately EUR 4.2 million, with customer satisfaction scores flat and time-to-resolution rising.

Under a production AI engagement, Discover maps the enquiry types, the resolution paths, the integration points with the CRM and the help desk, and the regulatory boundaries. Design defines an AI assistant that triages the enquiry, classifies it, surfaces the relevant knowledge, and routes it to the right specialist with the context attached. Prototype builds a working version that handles 60% of the enquiries end-to-end and escalates 40% to a human with the right context. Integrate connects the assistant to the email, the CRM, the help desk, and the knowledge base. The system goes live. The annual agent time drops by approximately EUR 1.4 million, with customer satisfaction scores rising and time-to-resolution falling.