A mid-market company comparing AI options can easily compare the wrong things. A software subscription looks cheaper than a custom build, while a prototype built with an API looks faster than either. But the useful question is not “Which technology costs least?” It is “Which operating model gives this workflow the right fit, control, speed, and exit path?”
For a Brussels managing director or CIO, there are usually three choices. Buy a packaged product when the process is standard and the vendor already solves most of it. Build when the workflow creates real differentiation or needs controls that products cannot provide. Integrate when existing systems should remain the source of truth and AI must coordinate work across them. Many successful implementations are hybrids: buy a model or application, integrate it into the operating workflow, and build only the thin layer that is distinctive.
Start with the workflow, not a product list
Define one workflow from trigger to recorded outcome. A customer-response workflow might start when an email arrives and end when the CRM contains an approved answer, owner, and next action. An order-exception workflow might start with a mismatch in an ERP and end when a person approves a documented resolution. Name the inputs, systems, decisions, handoffs, exceptions, and accountable owner.
This boundary exposes what the AI solution must actually do. A packaged assistant may draft text well but lack the permissions, multilingual terminology, ERP objects, approval steps, or audit record that operations require. Conversely, a custom model is wasteful when a mature product already provides the needed feature and the process can adapt to it.
The three options in practical terms
Buy: standard capability, fast adoption
Buying is strongest when the process is common, configuration is sufficient, and time-to-value matters more than uniqueness. Examples include meeting transcription, basic document extraction, general productivity assistance, or a support feature already embedded in the company’s CRM. Assess the complete product rather than the demo: data location, processor terms, retention, access controls, export formats, administrative logs, service limits, model changes, support, and termination assistance.
The hidden risk is process compromise. Teams may bend a critical workflow around a vendor’s assumptions, create manual work between systems, or discover that export and deletion are weak. The EU Data Act has applied since 12 September 2025 and includes rules intended to make switching between data-processing services easier. That strengthens the case for testing portability, but it does not replace a concrete exit plan, usable exports, and contractual responsibilities.
Build: differentiated logic and deeper control
Building is appropriate when proprietary workflow knowledge matters, the decision logic is unusual, or security and control requirements cannot be met by standard products. “Build” rarely means training a foundation model from scratch. It usually means assembling existing models and infrastructure into a purpose-built application with the company’s data boundaries, evaluation set, interface, approvals, and monitoring.
The visible development cost is only part of ownership. Include product management, data preparation, integration, testing, security review, user support, model changes, incident response, and maintenance when source systems evolve. A custom system without a named product owner becomes an expensive prototype. Build only where the additional fit or differentiation can justify that continuing obligation.
Integrate: preserve systems of record, change the flow of work
Integration is often the practical middle path for Belgian and Dutch mid-market teams. The CRM, ERP, document store, or ticketing platform remains authoritative. AI extracts, classifies, retrieves, recommends, or drafts; an orchestration layer moves information between systems and sends uncertain cases to people. This avoids replacing a core platform merely to add one intelligent workflow.
Integration is not automatically simple. Every connector introduces authentication, field mapping, rate limits, version changes, logging, retries, and failure recovery. Test the exact objects and permissions required rather than accepting “there is an API” as proof. The architecture should state what happens when the model, connector, or source system is unavailable.
A seven-factor decision scorecard
Score each factor from one to five, document the evidence, and compare options with the same assumptions.
- Differentiation: Does this workflow create an advantage, or is it standard administration? Standard work favours buying; distinctive operating logic can justify building.
- Data sensitivity: Identify personal, confidential, regulated, and cross-border data. Higher sensitivity increases the importance of architecture, contracts, access control, and auditability.
- Integration depth: Count systems, write actions, custom objects, and dependencies. Deep integration often favours a controlled integration layer rather than a standalone tool.
- Time-to-value: Separate a fast demonstration from production readiness. Buying can reduce implementation time, but only if procurement, security, data, and adoption fit.
- Ownership capacity: Name who will operate, evaluate, support, and improve the system after launch. If nobody owns a custom product, do not build it.
- Maintenance exposure: Estimate changes to models, prompts, integrations, policies, and source systems over three years, not only the launch budget.
- Exit cost: Test data export, configuration portability, replacement effort, contractual notice, and continuity if a vendor changes price or capability.
Use the scorecard to reveal trade-offs, not manufacture a precise answer. A high-risk customer or employment decision may require stronger human control regardless of the cheapest score. A low-risk internal summarisation tool may justify a faster buy decision.
A Brussels and Benelux implementation workflow
- Map one production slice. In workshops with operations, IT, security, and the process owner, record the current baseline and the exceptions people handle manually.
- Classify data and decisions. Identify personal data, confidential records, affected people, automated actions, and where human review is mandatory. The EDPB explains that a DPIA is required where processing is likely to result in high risk; treat the assessment as an architecture input, not paperwork after procurement.
- Shortlist all three paths. Ask vendors to demonstrate the exact workflow using representative test data. Estimate the comparable custom and integration options with the same controls and support period.
- Check regulatory roles. Under the EU AI Act, obligations depend on the system and whether the organisation is a provider, deployer, importer, or distributor. AI literacy obligations have applied since 2 February 2025, while most provisions apply from 2 August 2026, with some exceptions. Record the classification and obtain legal advice where impact is material.
- Design the control boundary. Define permissions, approval thresholds, refusal and escalation behaviour, logs, retention, monitoring, and rollback. For multilingual Belgian operations, test Dutch, French, and English examples separately; do not assume performance transfers between languages.
- Run a measured production pilot. Use real users and real controls in a narrow scope. European Digital Innovation Hubs offer “test before invest” and related support that can help SMEs evaluate technology before broader commitment.
- Approve with an exit plan. Store architecture, evaluation results, contracts, ownership, export steps, and replacement assumptions alongside the investment decision.
Constraints that should change the answer
Do not build when the company lacks a stable source of truth, an owner, or capacity to support software. Do not buy when the product requires unacceptable data use, weak exports, or a process design that creates more manual work. Do not integrate a fragile process merely because APIs exist. First repair unclear ownership, duplicate data, and uncontrolled exceptions.
Procurement must also distinguish model risk from workflow risk. A reliable model can still produce a harmful outcome when permissions, context, or downstream actions are wrong. Conversely, an imperfect model may be useful when it only drafts a recommendation that a trained person must approve. Controls should match the consequence of failure.
Measure value without inventing savings
Record a baseline before selecting an option. Measure volume, active handling time, waiting time, rework, error and exception rates, escalation, and cost of delay. Choose one primary outcome, such as time from request to approved resolution, and guardrails such as correction rate, unsupported-answer rate, policy breaches, or incidents.
During the pilot, compare buy, build, and integrate on the same scorecard: outcome quality, user adoption, implementation effort, run cost, support burden, control coverage, and recovery from failure. Review after several operating cycles. Hours “touched” by automation are not automatically cash savings; value may instead appear as faster response, higher capacity, fewer errors, or better traceability. Expansion should require evidence that the workflow improved without moving hidden work to IT, finance, or operations.
Intyb helps mid-market teams turn this decision into a controlled production slice through custom AI solutions for organisations in Brussels and across the Benelux. Use our AI implementation cost guide to build comparable ownership assumptions, or discuss the workflow with Intyb.