Do Not Choose an AI Platform Until It Passes a Portability Drill

An enterprise AI platform is not a model leaderboard with an admin console attached. It is an operating dependency: prompts, retrieval, tools, safety rules, identities, telemetry, evaluations, and business decisions gradually conform to its abstractions. A platform can look cheapest and most capable during procurement while becoming the most expensive option two years later because the organization cannot reproduce its behavior anywhere else.

The practical response is not to demand perfect portability. That is usually unrealistic. It is to define which assets must remain portable, measure the cost of moving a representative workload, and deliberately price the dependencies that you choose to keep.

This article adapts AI-Due's comparison of enterprise AI platforms into a vendor-neutral decision system. The source correctly separates foundation models, enterprise suites, and specialist platforms. The missing procurement question is: if a provider changes price, removes a model, degrades a region, or no longer fits the risk boundary, can the organization move an important workflow without rebuilding its business logic from memory?

The answer should come from a drill, not a promise.

The decision in one sentence

Choose the platform that produces the best accepted business outcomes inside your risk and operating constraints, while keeping the cost and time of a tested exit below an explicit ceiling.

That sentence has four parts:

1. Accepted outcomes, not benchmark scores or attractive demonstrations.
2. Risk constraints, including data location, identity, authorization, audit, and human control.
3. Operating constraints, including latency tails, quotas, support, skills, and incident recovery.
4. A tested exit ceiling, expressed in time, money, lost functionality, and quality change.

If procurement measures only the first invoice and a generic accuracy score, it has not compared platforms. It has compared sales offers.

Why feature matrices fail

A conventional matrix gives every vendor a row and every advertised capability a column. The cells quickly turn green: chat, embeddings, agents, retrieval, fine-tuning, guardrails, regional hosting, connectors, monitoring. Yet identical labels can hide materially different semantics.

“Structured output” may mean a valid JSON response, schema-constrained decoding, or best-effort formatting. “Private data” may refer to training exclusion while leaving retention, abuse monitoring, subprocessors, and regional processing unanswered. “Agent tools” may use different retry, timeout, idempotency, and approval rules. “Evaluation” may measure model quality but not authorization failures or downstream rework.

Feature presence therefore has weak decision value. What matters is whether the complete workload behaves acceptably under your inputs, identities, load, failures, and evidence requirements.

The AI-Due platform comparison is useful as a market map: foundation-model providers, enterprise suites, and specialized platforms solve different layers of the problem. Treat that map as the beginning of discovery. Do not turn its product descriptions, indicative prices, or model claims into a purchase decision without current contractual and workload evidence.

Define the workload before comparing platforms

“We need an AI platform” is not a testable requirement. Define a workload packet instead. One packet describes one business outcome and contains everything needed to evaluate it consistently.

A useful packet includes:

• the decision or artifact the system must produce;
• representative inputs, including rare and adversarial cases;
• the data classes involved and prohibited destinations;
• permitted tools and maximum authority;
• required citations, evidence, or provenance;
• quality acceptance rules and abstention conditions;
• latency and availability objectives;
• expected volume and concurrency distribution;
• human review and escalation steps;
• retention, deletion, and audit requirements;
• a known-good baseline from the current process.

Use several packets rather than one synthetic prompt. A customer-support summarizer, a coding assistant, a multilingual document extractor, and a tool-using finance agent create different rankings. A platform that wins one may lose another.

Separate hard gates from scored preferences

Hard gates are binary. A platform is inadmissible if it cannot meet them. Examples include an approved processing region, single sign-on, tenant isolation, auditable tool approval, a required deletion path, or a contractual prohibition on training with customer data.

Preferences are scored after gates pass: response quality, integration effort, latency, cost, support, or developer experience. Never allow an excellent model score to compensate for a failed legal or security gate. A weighted spreadsheet that lets strengths offset prohibitions is mathematically tidy and operationally wrong.

Dimension	Example gate	Example scored measure	Evidence
Data	Approved processing and retention	Transfer overhead	Contract plus technical test
Identity	SSO and least privilege	Admin effort	Configuration export and access test
Quality	Critical error rate below ceiling	Accepted outcome rate	Frozen evaluation set
Operations	Required region and support path	P95/P99 latency	Load and incident test
Tools	Explicit approval for high-impact actions	Completion rate	Sandbox traces
Exit	Required assets exportable	Migration hours and quality delta	Portability drill

Build a platform-independent control plane

Portability begins with ownership boundaries. The enterprise should own the workload definition, evaluation set, policy, business rules, outcome history, and route decision. Providers can supply excellent models, hosting, connectors, and managed controls without becoming the only place where the organization understands how its work is performed.

flowchart LR
    U[User or business event] --> I[Enterprise identity and policy]
    I --> R[Workload router]
    R --> A[Platform A adapter]
    R --> B[Platform B adapter]
    R --> L[Local or private endpoint]
    A --> V[Output validator]
    B --> V
    L --> V
    V --> H{Human approval required?}
    H -->|yes| Q[Review queue]
    H -->|no| X[Bounded action]
    Q --> X
    X --> O[Outcome and evidence ledger]
    O --> E[Evaluation and routing updates]

This diagram does not imply that every request must be dynamically multi-cloud. It shows where durable enterprise assets should sit. A single provider can remain the default. The boundary simply prevents prompts, permissions, evaluations, and outcome semantics from being trapped inside a proprietary studio with no reproducible representation.

What belongs outside the provider-specific layer

Keep the following assets under enterprise version control when feasible:

• workload schemas and task instructions;
• evaluation cases and acceptance thresholds;
• retrieval source identifiers and authorization mappings;
• tool contracts, idempotency keys, and approval rules;
• output schemas and validators;
• routing rules and fallback prohibitions;
• redaction and retention policies;
• outcome labels, reviewer decisions, and incident records;
• dependency and configuration manifests.

Provider adapters translate those assets into each platform's API or managed features. Some functionality will remain proprietary. Record it explicitly as a dependency with an owner, benefit, replacement option, and exit estimate.

Run an evaluation that measures completed work

Public benchmarks are useful context, not acceptance tests. MLCommons explains that MLPerf Inference uses defined datasets, quality targets, load scenarios, and rules to compare system performance in a reproducible way. Its datacenter suite measures latency and throughput under specified conditions, which is far stronger than an undocumented vendor chart (MLCommons). But even a strong infrastructure benchmark does not know your policies, documents, tool errors, review costs, or customer consequences.

Create a frozen enterprise evaluation set. Preserve the same inputs, expected evidence, tool fixtures, policies, and scoring logic across candidates. Include ordinary cases, long-tail cases, malicious instructions, missing information, ambiguous requests, unavailable tools, rate limits, and permission denials.

Measure at least:

• accepted outcome rate;
• critical error rate;
• correct abstention rate;
• evidence or citation validity;
• tool-selection and argument accuracy;
• unauthorized-action attempts;
• human review minutes;
• downstream rework;
• P50, P95, and P99 end-to-end latency;
• successful recovery after timeout or partial failure;
• total variable and fixed cost per accepted outcome.

Do not mix all cases into one average. Segment by risk, language, input length, tool count, and complexity. A 92% average can hide a 40% success rate on the regulated cases that justified the purchase.

Use paired comparisons

Send the same case to each candidate under controlled settings. Blind reviewers to the provider when practical. Store raw outputs securely, but score normalized outcomes with the same rubric. Where outputs are subjective, use multiple reviewers and record disagreement rather than manufacturing precision.

Repeat a subset across days and load levels. Generative systems can vary, and managed platforms change. The goal is not to declare an eternal winner. It is to establish an evidence snapshot with enough variance information to support a bounded decision.

Why one score is not enough

The research record supports multi-dimensional comparison. The HELM project evaluated language models across scenarios and, where feasible, seven dimensions: accuracy, calibration, robustness, fairness, bias, toxicity, and efficiency. Its authors also found that prominent models had often been tested on only a small fraction of the same core scenarios before standardization improved coverage (HELM paper). The procurement lesson is not to copy HELM's exact suite. It is to resist collapsing incompatible concerns into one leaderboard number.

Maintain a scorecard with separate floors. A platform that is fast but violates an authorization rule fails. A platform that is accurate on routine English requests but unreliable for the languages your customers use needs a segmented decision. A platform that wins quality by consuming far more review labor should expose that cost rather than hiding it inside an aggregate score.

Also preserve test limitations. Evaluation cases are samples, graders can disagree, and production distributions move. Record coverage, excluded populations, confidence intervals where defensible, and the date of every result. Revalidation should be triggered by meaningful model, policy, retrieval, tool, or workload changes—not merely by a calendar reminder.

Calculate cost at the accepted-outcome boundary

Token price is only one term. The relevant unit is the cost of a business result that passes acceptance.

Use:

cost_per_accepted_outcome =
  (platform_fees
   + model_usage
   + retrieval_and_storage
   + integration_labor
   + operations_and_security
   + human_review
   + rework
   + expected_failure_cost)
  / accepted_outcomes

A cheaper model that produces more rework can cost more. A managed suite with a higher license may be economical if it removes identity, observability, and support work that the organization would otherwise perform. Conversely, bundled credits can disguise high switching and administration costs after usage grows.

Model price changes, caching, batch discounts, reserved capacity, region premiums, and tool-call expansion with realistic traffic distributions. Include unsuccessful calls and retries. Estimate the cost of incident response and temporary manual fallback. State every assumption and rerun the model when the provider or workload changes.

Measure lock-in instead of arguing about it

Lock-in is neither automatically bad nor fully avoidable. Organizations accept dependencies because integrated services accelerate delivery. The right question is whether the dependency is understood, priced, monitored, and reversible enough for the workload.

BCG reports that 62% of 500 surveyed IT decision makers were concerned about digital-platform lock-in, while 79% said the value justified the cost. That tension is important: dependency can coexist with value (BCG). The aim is not purity. It is informed exposure.

Create a dependency ledger with these categories:

1. Data dependency: prompts, files, embeddings, indexes, fine-tuning data, feedback, and logs.
2. Behavior dependency: system instructions, hidden orchestration, safety behavior, and model-specific prompt conventions.
3. Tool dependency: proprietary connectors, action semantics, retries, approvals, and state.
4. Identity dependency: users, groups, service principals, permissions, and audit roles.
5. Operational dependency: quotas, regional capacity, dashboards, alerts, incident processes, and support.
6. Commercial dependency: commitments, discounts, egress, minimum spend, termination terms, and price-change rights.
7. Skill dependency: expertise that exists only in a vendor studio or configuration language.
8. Cognitive dependency: business logic that teams can no longer explain without the platform.

For each dependency, record the benefit, replacement path, export format, estimated migration effort, evidence freshness, and maximum tolerated outage.

The portability drill

A questionnaire asks whether switching is possible. A drill discovers what switching means.

Select one representative, production-shaped workload. It should be valuable enough to expose real complexity but bounded enough to migrate safely in a test environment. Freeze its current version and baseline results. Then move it to a second platform or a local compatible endpoint.

Step 1: inventory the complete workload

Export prompts, schemas, retrieval documents, chunking settings, embeddings assumptions, tool definitions, policy rules, identities, secrets references, evaluation cases, telemetry fields, and approval flows. Do not export live secrets or personal data into an uncontrolled test environment.

Mark anything that cannot be exported. “We can recreate it” is not equivalent to an export until someone reproduces it and verifies the result.

Step 2: implement the smallest adapter

Translate model calls, structured outputs, streaming events, and tool invocation into a neutral internal contract. Avoid normalizing away meaningful differences. If Platform B lacks a feature, implement a visible substitute or record the gap.

const workload = {
  id: "support-resolution-v3",
  input: { ticketId: "T-1042", locale: "en-GB" },
  policy: { maxRisk: "low", requireEvidence: true },
  outputSchema: {
    type: "object",
    required: ["decision", "evidence", "confidence"],
  },
};

async function runWith(provider, packet) {
  const start = performance.now();
  const raw = await provider.execute(packet);
  const validation = validateOutput(raw, packet.outputSchema);
  return {
    provider: provider.name,
    accepted: validation.ok && policyAllows(raw, packet.policy),
    latencyMs: Math.round(performance.now() - start),
    reasons: validation.reasons,
    output: raw,
  };
}

const result = await runWith(selectedAdapter, workload);
console.log(JSON.stringify(result, null, 2));

In production, add authenticated identities, timeouts, idempotency, redaction, durable evidence, and bounded retries. The important pattern is that the business packet and validator do not belong to the provider adapter.

Step 3: replay the frozen evaluation

Run both implementations on identical cases. Compare accepted outcomes, critical failures, abstentions, latency distribution, review time, and cost. Investigate semantic differences. A syntactically compatible API can still produce different tool timing, refusal behavior, context handling, or evidence quality.

Step 4: test operational failure

Simulate quota exhaustion, regional unavailability, malformed tool output, slow retrieval, expired credentials, and partial streaming. Confirm that fallback behavior respects data and risk policy. A sensitive workload must not silently route to an unapproved provider merely because the default is unavailable.

Step 5: account for the move

Track engineering hours, security review, data movement, contract work, retraining, parallel running, reviewer time, degraded features, and remaining cleanup. Measure elapsed calendar time as well as labor. A five-day implementation that waits six weeks for contractual or regional approval is a six-week exit.

Step 6: produce an exit receipt

The receipt records:

• workload and versions tested;
• source and destination platforms;
• assets successfully exported and reconstructed;
• features lost, substituted, or redesigned;
• quality, latency, and cost deltas;
• labor and elapsed time;
• unresolved dependencies;
• rollback result;
• next drill date.

Set thresholds before the test. For example: no critical-policy regression, less than five percentage points loss in accepted outcomes, recovery within one business day, and migration below 15 person-days. Your thresholds will differ, but retrospective rationalization is not a control.

Portability law helps, but it does not migrate your application

The EU Data Act has applied since 12 September 2025. Its Chapter VI addresses switching between data-processing services and requires measures intended to remove switching obstacles. The European Commission explains that relevant customer input, output, and metadata are part of the switching scope, that SaaS and PaaS providers must make open interfaces available and export data in a commonly used machine-readable format, and that switching and egress charges are due to be removed from 12 January 2027 (European Commission).

This is meaningful leverage, not a substitute for engineering. Exportable data does not automatically reproduce prompts, retrieval ranking, model behavior, tool semantics, identities, approvals, observability, or accepted outcomes. Legal scope may also vary by service and asset; protected intellectual property and trade secrets affect what is included. Obtain legal advice for your contract and jurisdiction rather than treating this article as legal guidance.

Use regulation to strengthen contract questions, then prove technical and operational portability with the drill.

Contract for evidence, not adjectives

Procurement language should be concrete enough to verify. Ask for:

• processing locations and subprocessors by service and feature;
• retention, deletion, backup, and abuse-monitoring behavior;
• exportable asset list, formats, interfaces, time limits, and assistance;
• change notice for models, APIs, regions, safety behavior, and prices;
• version pinning or migration windows where available;
• service objectives and remedies by region;
• incident notification and evidence access;
• audit-log fields, retention, and export;
• termination assistance and credential revocation;
• ownership and permitted use of inputs, outputs, tuning data, and feedback;
• a tested path for bulk export without production interruption.

Avoid relying on “enterprise-grade,” “secure,” “open,” “portable,” or “responsible” unless the contract, configuration, and test evidence define the claim.

Contradictions and trade-offs

More abstraction can improve portability and reduce useful capability

A lowest-common-denominator gateway makes providers easier to swap, but it may hide valuable features such as constrained decoding, prompt caching, regional capacity controls, or native tool governance. Preserve a neutral core, then allow declared extensions. Test whether each extension earns its dependency.

Multi-platform architecture can improve resilience and increase failure surface

Two providers introduce two identities, policies, billing systems, incident paths, and behavior profiles. Multi-platform is not automatically safer or cheaper. Use it where the recovery or specialization benefit exceeds the operating burden.

Open weights can reduce provider dependence and create new dependence

Self-hosting changes the dependency from an API vendor to model artifacts, serving infrastructure, accelerators, security updates, and scarce operational skills. It can be the right choice, but it is not dependency-free.

The best model today may be the wrong platform decision

Model rankings move quickly. Enterprise integration and governance move slowly. Prefer a platform and control plane that can absorb model change without repeatedly rebuilding policy and evidence. At the same time, do not sacrifice a critical outcome merely for theoretical interchangeability.

A successful export does not prove equivalent behavior

Files and metadata can move while functionality degrades. The Commission's description of “functional equivalence” for shared infrastructure features does not mean generative models will return identical judgments. Portability acceptance must include outcome evaluation.

Failure modes and controls

Failure mode: demo winner

The team selects the most impressive hand-picked demonstration.

Control: use frozen representative packets, blind scoring, risk segments, and repeated tests.

Failure mode: token-price procurement

The business ignores integration, review, rework, operations, and failure cost.

Control: compare total cost per accepted outcome under realistic traffic.

Failure mode: weighted-gate bypass

A high capability score offsets a failed security or legal requirement.

Control: apply hard admissibility gates before weighted scoring.

Failure mode: proprietary-policy trap

Business rules exist only in a vendor console and cannot be reproduced.

Control: version neutral policy definitions and record platform translations.

Failure mode: silent fallback

A failed primary route sends sensitive data to an unapproved endpoint.

Control: bind fallback to data and action policy; fail closed when no approved route exists.

Failure mode: benchmark theater

The team quotes public performance results that do not match its workload.

Control: use public benchmarks for context and internal packets for acceptance.

Failure mode: paper portability

The contract promises export, but no one has restored a working workload.

Control: run a timed migration and retain an exit receipt.

Failure mode: abandoned source platform

After a test migration, data, credentials, indexes, or logs remain in the old environment.

Control: include verified revocation, deletion, retention expiry, and billing closure in the exit plan.

Failure mode: evaluator capture

The same vendor feature generates, judges, and explains outputs.

Control: keep business acceptance logic independent and use human or cross-system checks for critical cases.

A 90-day selection sequence

Days 1–15: frame

Choose three to five workload packets. Establish hard gates, baselines, outcome metrics, risk owners, and an initial dependency ledger. Remove candidates that cannot meet gates.

Days 16–35: evaluate

Implement thin adapters and replay the frozen cases. Test quality, evidence, tools, latency, load, denial, and failure recovery. Model total cost per accepted outcome.

Days 36–50: drill exit

Move one workload between the two leading candidates. Time the work, test reconstruction, compare outcomes, and produce the exit receipt.

Days 51–65: contract

Use the evidence to negotiate regions, changes, export, support, termination, and pricing. Resolve gaps or formally accept them with an owner and exposure limit.

Days 66–90: controlled production

Launch a bounded population with human review and explicit rollback. Monitor accepted outcomes, critical errors, tail latency, review effort, cost, and dependency changes. Do not expand until the production evidence meets the predeclared gates.

Validation checklist

Before approving an enterprise AI platform, verify:

• [ ] Workload packets describe outcomes, inputs, risks, tools, and baselines.
• [ ] Hard gates are separated from weighted preferences.
• [ ] Every candidate received the same frozen evaluation cases.
• [ ] Results are segmented by risk, language, complexity, and load.
• [ ] Accepted outcomes, critical errors, abstentions, and rework are measured.
• [ ] P50, P95, and P99 end-to-end latency are measured under realistic concurrency.
• [ ] Cost includes integration, operations, review, rework, and failure.
• [ ] Business rules, policies, validators, and evaluation cases remain enterprise-owned.
• [ ] Retrieval authorization is preserved outside provider-specific shortcuts.
• [ ] Tool calls use typed contracts, least privilege, approval, and idempotency.
• [ ] Platform-specific extensions have explicit benefits and exit estimates.
• [ ] Data, behavior, tools, identity, operations, commercial, skill, and cognitive dependencies are logged.
• [ ] Export formats and interfaces have been exercised, not merely documented.
• [ ] One representative workload has been migrated and replayed.
• [ ] Quality and policy deltas after migration remain within declared ceilings.
• [ ] Fallback routes cannot bypass data or action restrictions.
• [ ] Regional outage, quota, credential, and partial-failure scenarios have been tested.
• [ ] Contract terms cover location, retention, changes, export, incidents, and termination.
• [ ] Cleanup covers credentials, data, indexes, logs, commitments, and billing.
• [ ] The exit receipt has an owner and a future drill date.

The final decision rule

Do not buy the platform with the longest feature list, the most famous model, or the cheapest million tokens. Buy the operating arrangement that passes your hard gates, delivers the strongest accepted outcomes for the full cost, and keeps chosen dependencies within a tested exit budget.

The goal is not to switch providers constantly. The goal is to retain the ability to make a real choice when conditions change. A portability drill converts that ability from procurement language into evidence.