AI Technology Brief
Should your construction operating system survive a change of AI provider?
AI models, APIs, providers, licences, and deployment routes will change. Construction and property businesses should retain durable records, workflow state, permissions, approvals, evidence, and operating history while treating hosted proprietary, open-weight, managed, and self-hosted options as distinct dependencies.
01 / Independently verifiable claims
Begin with what the technology and standards actually support.
- IBM reported that 71% of 1,000 surveyed senior executives said switching their primary AI vendor or model would be difficult. The IBM Institute for Business Value and Oxford Economics conducted the global survey between February and April 2026 across 16 countries and 17 industries.
- IBM reported that 91% of respondents did not fully understand their organization's dependencies across AI vendors, models, and infrastructure. This is a survey finding, not a universal measure of every enterprise.
- IBM reported that 81% of respondents said a seven-day vendor outage would cause severe or critical disruption. The finding supports contingency planning; it does not predict the likelihood or impact of a specific provider outage for a buyer.
- BCG describes an enterprise ontology containing proprietary knowledge, business concepts, relationships, and rules as a strategic asset that should remain under enterprise control rather than being outsourced wholesale.
- BCG recommends a model gateway as a shared access layer for models from multiple providers, quota and cost controls, and model switching without rewriting application code.
- BCG separates model choice, workload architecture, and enterprise platform or control-plane choice. Portability depends on more than token price because knowledge, memory, orchestration, governance, monitoring, tools, and connectors can create deeper coupling.
- NIST AI RMF GOVERN 6 addresses third-party risk policies and contingency processes. Its supporting guidance includes inventorying third-party models, software, data, contracts, service levels, changes, dependencies, and failure plans.
- Microsoft documents abstraction layers, model routers, and unified model APIs across multiple backends. These can reduce application-level coupling but do not make provider behavior, tool use, safety controls, context, or outputs identical.
- OpenAI and Anthropic publish model lifecycle, deprecation, retirement, and migration guidance. Production buyers should expect model and API change rather than treating one model identifier as permanent infrastructure.
02 / The practical distinction
Keep durable operating knowledge separate from replaceable intelligence and commercial infrastructure.
The buyer does not need to own every server. The buyer does need to know which layer contains irreplaceable business meaning and what happens when a provider changes.
Own
Operating records
Stable customer, project, property, organization, contact, document, work-item, source, run, review, decision, and accepted-output IDs with source-system crosswalks.
Own
Workflow and rules
Triggers, states, required fields, validation, assignments, exceptions, deadlines, permissions, approvals, acceptance, correction, and event history.
Control
AI access layer
Logical task contracts, provider adapters, model registry, routing, credentials, quotas, cost, logging, evaluations, fallback, interruption, and release policy.
Replace
Models and providers
Hosted, cloud, specialist, open-weight, or future models selected by tested task performance, terms, region, latency, cost, and operating consequence.
03 / Operating architecture
Put the business contract above the model contract.
Applications should request a bounded business capability using stable records and an explicit output schema. A governed access layer then selects an evaluated provider without transferring record authority or approval to that provider.
Company operating layer
Authoritative and derived records, stable IDs, relationships, source evidence, definitions, permissions, workflow state, business rules, accepted decisions, and correction history.
Task contract
Task ID, purpose, approved input schema, prohibited data, output schema, evidence requirements, critical failures, review gate, timeout, and acceptable degradation.
Governed AI gateway
Provider adapter, logical model alias, credentials, region, retention terms, routing policy, quotas, telemetry, policy enforcement, retry, failover, and cost records.
Evaluated providers
Pinned model versions or deployments tested against representative cases. Provider-specific features remain isolated behind documented adapters where practical.
04 / Required records
A replaceable model still requires a complete dependency and decision record.
Provider and contract
Provider, service, region, subcontractors, terms, data use, retention, deletion, ownership, service level, notification, suspension, export, termination, and dispute route.
Model and capability
Model ID, pinned version or deployment, lifecycle state, modality, context, tools, structured output, safety settings, known limits, replacement, and retirement date.
Business task
Task ID, workflow ID, owner, purpose, approved records, maximum authority, output schema, reviewer, acceptance, critical failure, and prohibited action.
Prompt and orchestration
System instructions, templates, retrieval policy, tools, deterministic functions, agent logic, memory boundary, configuration version, and provider-specific dependencies.
Run and evidence
Run ID, source IDs, input hashes, model and configuration versions, tool calls, output, citations, latency, tokens, cost, errors, review, and accepted-output ID.
Exit and recovery
Export formats, data location, credential revocation, replacement adapter, evaluation set, replay procedure, fallback operation, deletion evidence, owner, and last tested date.
05 / Construction example
An estimating assistant should be replaceable without reconstructing the estimating business record.
This is an architecture example, not a claim that two models will produce equivalent takeoffs, scope interpretations, rates, risk judgments, or commercial decisions.
Retain
Company-owned estimate context
Project ID, bid ID, document and revision IDs, scope package, assumptions, exclusions, quantity records, quote IDs, cost codes, source citations, estimator review, and accepted estimate version.
Contract
Bound the AI task
Ask the model to classify requirements or prepare candidate fields against a fixed schema. Keep measurement logic, rates, calculations, estimate class, contingency, and submission authority outside the model.
Compare
Run replacement evaluations
Replay representative normal, incomplete, conflicting, multilingual, table-heavy, and high-consequence cases against the current and candidate model using the same accepted evidence.
Decide
Retain estimator authority
The estimator inspects sources, corrections, missed scope, quantities, commercial conditions, reviewer effort, and critical failures before accepting any output or provider change.
06 / Deterministic controls
Design portability into records, interfaces, evaluation, and procurement before dependency becomes operational.
Inventory every dependency
Map model, provider, cloud, embeddings, vector store, memory, orchestration, tools, safety services, identity, monitoring, data, contracts, skills, and subcontractors.
Use stable business schemas
Keep provider response objects out of authoritative tables. Transform candidate outputs into a company-controlled schema with source IDs, validation, review, and acceptance state.
Isolate provider features
Place proprietary tool calls, prompt caching, assistants, memory, search, computer use, and response formats behind documented adapters when the portability benefit justifies the work.
Pin and monitor versions
Use pinned versions where supported, monitor lifecycle notices, record every run version, maintain migration ownership, and rerun evaluations before changing aliases.
Preserve human fallback
Define how people receive, perform, prioritize, and record the work when the model, provider, gateway, integration, or evaluation boundary is unavailable.
Test the exit package
Export records and configuration, revoke credentials, deploy a replacement adapter, replay accepted cases, reconcile outputs, confirm deletion obligations, and record remaining dependencies.
07 / Failure analysis
A nominally multi-model system can remain deeply locked in or become less dependable.
Prompt portability illusion
The same prompt produces materially different tool calls, citations, classifications, refusals, structured fields, or omissions across providers.
Hidden state stays behind
Conversation memory, files, vector indexes, fine-tunes, agent state, feedback, evaluations, or learned context cannot be exported in a usable form.
Gateway becomes the new lock-in
Applications avoid direct model coupling but depend completely on one gateway's routing, policy, telemetry, proprietary schema, identity, or deployment environment.
Lowest-common-denominator design
Avoiding every provider feature removes useful capability, increases custom code, or reduces quality without a buyer-specific continuity benefit.
Failover without acceptance
Traffic moves to another model during an outage even though that model has not passed the task's current evaluation or critical-failure rules.
Data ownership is assumed
The contract does not clearly cover prompts, uploaded files, outputs, extracted records, metadata, logs, fine-tunes, deletion, export, or post-termination access.
Cost moves rather than falls
Multi-provider operation adds integration, evaluation, monitoring, security, skills, duplicated capacity, migration, and support costs that token comparisons omit.
Authority follows the provider
Vendor-specific agents silently accumulate write access, approval-like behavior, external communication, or business rules that are absent from the company workflow record.
Release churn drives architecture
A team repeatedly changes models because of weekly rankings, demonstrations, or price claims without a stable task contract, regression set, migration record, or accepted business reason.
08 / Deployment and cost
Choose the portability depth from consequence, switching need, provider concentration, and total operating cost.
Documented single provider
Appropriate for low-consequence work when the buyer retains records, schemas, prompts, evaluations, exports, manual fallback, lifecycle monitoring, and an explicit accepted dependency.
Portable task contract
Use a stable company schema and adapter boundary for recurring workflows where model replacement is plausible but active multi-provider routing is unnecessary.
Evaluated multi-provider gateway
Use when continuity, regional availability, workload routing, procurement leverage, or specialist capability justifies parallel adapters, evaluations, monitoring, and operational ownership.
Controlled self-hosted option
Evaluate when privacy, location, latency, specialized models, or continuity justify infrastructure and model-operation responsibility. Self-hosting does not remove dependency on hardware, software, licenses, skills, and updates.
- Provider, model, cloud, gateway, observability, storage, networking, security, support, minimum commitment, and regional capacity
- Stable schemas, adapters, orchestration separation, model registry, logical aliases, version management, and integration tests
- Representative evaluation cases, accepted outputs, critical-failure rules, regression runs, reviewer time, and correction records
- Data export, normalization, vector or memory migration, fine-tune replacement, prompt revision, tool adaptation, and output reconciliation
- Parallel provider contracts, duplicated controls, specialist skills, incident response, failover capacity, and operational complexity
- Manual fallback, outage backlog, delayed work, degraded operation, business interruption, recovery, and accepted-risk ownership
- Documentation, runbooks, administration, training, handover, credential transfer, deletion verification, and tested exit exercises
09 / Evaluation
Measure accepted task performance and migration work, not API compatibility alone.
- Schema validity, required-field completeness, source citation, native-ID preservation, unsupported assertions, and prohibited data handling
- Task accuracy, retrieval quality, tool selection, deterministic calculation agreement, critical omissions, and high-consequence failure rate
- Performance across normal, incomplete, conflicting, multilingual, long-context, table-heavy, portal, document, and adversarial cases
- Reviewer acceptance, correction type, review time, escalation, missed consequence, and accepted cost per business outcome
- Latency, throughput, timeout, rate limit, retry behavior, outage behavior, backlog recovery, and manual fallback capacity
- Prompt, tool, schema, memory, retrieval, safety, and orchestration changes required for the replacement model
- Export completeness, configuration portability, credential revocation, deletion evidence, replacement deployment time, and unresolved dependency
- Total operating cost across providers, gateway, infrastructure, evaluation, review, integration, monitoring, migration, support, and skills
10 / Controlled pilot
Prove the operating boundary before expanding it.
Select one bounded task
Choose document classification, requirement extraction, project-record matching, report preparation, or another task with stable evidence and accountable review.
Freeze the business contract
Define source IDs, allowed data, required schema, deterministic rules, prohibited actions, expected evidence, review, acceptance, and critical failures independently from a provider.
Baseline the current model
Record pinned model, prompts, tools, retrieval, accepted cases, reviewer effort, latency, cost, errors, and provider-specific features.
Implement one replacement
Use a separate adapter, preserve the same business contract, identify unavoidable differences, and do not route production work before evaluation.
Run outage and migration drills
Disable the primary route, activate the approved fallback or human process, reconcile queued work, export the operating package, and revoke test credentials.
Accept the dependency explicitly
Decide which coupling is justified, which exit work remains, who owns migration, what triggers replacement, and when the test must be repeated.
Buyer classification test
Classify what the system controls before accepting the label.
- 01
Can the buyer export authoritative and derived records with stable IDs, source crosswalks, relationships, versions, permissions, and accepted state?
- 02
Are business rules, approval gates, workflow state, and decision history stored outside model conversation memory and vendor-specific agents?
- 03
Can another evaluated model receive the same bounded task contract without rewriting the complete business application?
- 04
Are provider-specific tools, memory, retrieval, caching, safety, and output formats identified rather than hidden behind a generic AI label?
- 05
Can the workflow continue in a controlled degraded or human mode during a seven-day provider outage?
- 06
Has the buyer executed the exit package, replacement evaluation, credential revocation, data reconciliation, and deletion check rather than reviewing documents only?
11 / StructuredLayer recommendation
Own the operating context, document the accepted dependencies, and make model replacement a tested option where business consequence justifies the cost.
Do not pursue model neutrality as an abstract technical goal. Start with one buyer-owned record and workflow contract, isolate only the provider coupling that creates meaningful continuity or procurement exposure, maintain current evaluations and a human fallback, and test the exit package. A provider may remain a deliberate long-term dependency, but the buyer should know what it owns, what it rents, what breaks, who decides, and how operation continues.
12 / Primary sources
Capability, governance, and implementation claims remain inspectable.
IBM Newsroom
IBM study: limited control and rising dependencies leave enterprises exposed
IBM Institute for Business Value
The calculus of AI sovereignty
BCG
Your AI won't scale without a shared language
BCG
How AI is paying off in the tech function
BCG
Cloud AI costs: beyond token pricing decisions
Moody's
Artificial intelligence, digital finance, cyber risk, and data centers
NIST
AI Risk Management Framework Core
NIST
Generative Artificial Intelligence Profile
Microsoft Learn
Choose the right AI model for your workload
Microsoft Learn
Create and manage a unified model API
OpenAI
API backward compatibility
Anthropic
Model deprecations
Meta
Llama models and resources
Meta
Open-weight AI
Sources reviewed 12 August 2026. Technology capabilities, laws, guidance, terms, and pricing can change.
13 / Related StructuredLayer guidance
Continue from model selection into operating architecture.
Construction Operating Systems Toolkit
Use the Source-of-Truth Matrix, Stable Record ID Planner, Integration Boundary Check, AI Agent Authority Matrix, and Data Health Check before selecting an AI provider architecture.
Why ChatGPT or Claude is not the source of truth
Keep AI synthesis separate from authoritative records, permissions, versions, lineage, conflicts, correction, and business acceptance.
AI Agent Authorization
Separate technical tool access from identity, resource permission, exact action approval, external policy enforcement, and business authority.
Operating-Layer Blueprint
Define the buyer-owned data model, workflow, authority, system boundaries, evaluation, implementation options, ownership, and handover before committing to a build.