There is a procurement pattern that defines too many public-sector technology projects. A vendor proposes a platform. The platform is comprehensive. The platform requires significant configuration to fit the actual workflow. The configuration is expensive. The result is a workflow shaped to fit the platform, rather than a platform shaped to fit the workflow. Five years later, the platform is locked in, the workflow has accreted around it, and replacing either becomes a multi-year program. This pattern is so common in public-sector technology that it is rarely questioned. The permit case questioned it, and the answer mattered.
What was actually built
Three things, each chosen for replaceability rather than capability. An intake form designed with open web standards, deployable in any hosting environment. A case-routing rules engine implemented as a small body of configuration that any technical team can read, modify, and own. A dossier-preparation layer that retrieved documents from existing systems via standard APIs rather than embedding into a proprietary records system. Each component could be replaced independently if a better option appeared. The architecture had no single component whose replacement would require rebuilding everything else. This was a deliberate choice, and it was the choice that made the project possible to deliver on the timeline and budget the public body had available.
Procurement is the lesson. The AI is the easy part.
The vendor alternative
The alternative under consideration was a comprehensive case-management platform offered by a multinational vendor. The platform had everything: intake, workflow, routing, document management, analytics, citizen portal, integrated payment. It also had a six-figure annual licensing cost, a multi-quarter implementation timeline, and a configuration model that required vendor consultants for every meaningful change. The total five-year cost of ownership was approximately four times the cost of the open-tooling alternative. The functionality delivered was, in practical use, roughly the same. The difference was not capability. The difference was control.
Why the open-tooling approach worked
Three reasons specific to public-sector work. First, the workflow being automated was Belgian-specific, with category definitions, legal references, and language requirements that no off-the-shelf platform handled correctly out of the box. Any deployment was going to be heavily customized regardless. The open approach made the customization first-class rather than treating it as configuration around a fixed platform. Second, the technical capacity inside the public body was higher than is typical, with developers who could maintain the system once delivered. The capability transfer that ended the project meant the public body owned what it was running. Third, the budget cycle of the public body did not favor large licensing commitments. The open approach paid for the work to build the system once and then required only modest ongoing maintenance, which fit the annual budget cycle better than perpetual licensing.
When the vendor approach is right
It would be misleading to argue that the open approach always wins. There are cases where buying a vendor platform is the right answer. Small public bodies without technical capacity in-house cannot maintain custom systems. Standardized workflows where the public body genuinely is doing the same thing as many other public bodies can amortize platform costs across users. Time-critical deployments where six months of custom build is unacceptable can justify the higher long-term cost. The vendor approach is not wrong as a category. It is wrong as a default. The right question to ask first is whether this specific public body, with this specific workflow, has the technical capacity and the time to build instead of buying. The answer for the permit case was yes. For another case, the answer would be no.
The OECD pattern across documented deployments
The OECD's 2024 review of 200 government AI deployments found a consistent pattern in the successful cases: a strong focus on internal capability development, alignment of the deployment with existing administrative procedures rather than new platforms imposed on top of them, and explicit human oversight built into the workflow design [1]. The France Albert example is illustrative: a sovereign generative AI developed by the French DINUM, tested by 60 agents across 30 France Services centres in early 2024, with human agents retaining control of final interactions [2]. The architecture choice (sovereign, open, integrated into existing workflows) was as deliberate as the technology choice. The successful deployments are the ones that take the architecture decision seriously, not just the AI capability decision.
Optionality is hard to value in advance and obvious in retrospect.
The hidden cost of vendor lock-in
The five-year cost comparison understates the actual difference because the open approach preserves optionality. Five years after deployment, the public body can change vendors, integrate new tools, adopt new approaches, deprecate components that are no longer useful. The vendor approach makes each of these decisions more expensive because each one risks breaking the integrated platform. Optionality is hard to value in advance and obvious in retrospect. Public bodies that have lived through one or two vendor lock-in cycles tend to weigh this heavily; bodies that have not yet experienced it tend to underweight it.
The EU AI Act compliance angle
The EU AI Act's high-risk-system rules, applying from August 2026, require documentation of training data, accuracy and bias evaluation, post-deployment monitoring, and human oversight authority [3]. For vendor-installed systems, these requirements pass through to the public body but the underlying systems are not fully transparent to the body running them. Compliance becomes harder, not easier, because the body cannot inspect the vendor's models or training data without contractual access that vendors are often reluctant to provide. Open-tooling deployments do not eliminate the compliance burden, but they make the documentation tractable. For Belgian and EU public bodies preparing for full Act applicability, this is a procurement consideration that has not yet been priced into most vendor RFPs.
What this means for procurement
Three procurement principles, derived from the permit case and similar work. First, separate the architecture decision from the technology decision. Choose how you want to own the system before choosing what technology to use. Second, require interface specifications, not just capability descriptions, in any RFP. The interfaces determine replaceability. Capability determines whether the system works on day one; interfaces determine whether it works on day three thousand. Third, budget for change. Whatever the deployment costs, the changes after deployment will cost two to three times that over a five-year horizon. The procurement that minimizes change cost wins on total ownership, even if it loses on initial price.
The closing observation
The technology in the permit case was not novel. The patterns used were well-documented. The result, a 71 percent reduction in decision time without changing approval thresholds, was achievable in many configurations. What made this specific project work was the procurement architecture, not the technology. Public bodies considering similar deployments would benefit more from rethinking their procurement approach than from selecting different AI vendors. The procurement is the lesson. The AI is the easy part.
