Data portability in AI software: a guide to assessing lock-in risk

Portability in an application with artificial intelligence features is about more than downloading a file. It means being able to retrieve data, understand what information accompanies it, and determine which parts of the work can still be used outside the service. If a tool generates reports, classifies documents or automates tasks, the practical question is whether a business can take the inputs and outputs it needs to continue operating. The ability to export does not, by itself, guarantee that the result can be reused.

It is useful to distinguish between data supplied by the customer, outputs generated by the application, and elements that belong to the provider or depend on its infrastructure. This distinction matters because documentation may define export categories and exclusions differently. Do not assume that history, instructions, settings or connections to other systems are automatically included in a download. Each element must be checked separately.

Portability also has an operational dimension: an exported file may be complete yet require a particular format, tool or process to be brought into another system. A useful assessment therefore goes beyond asking, “Can I download my data?” It asks which categories the export covers, how they are delivered and what dependencies might prevent their later use. In this guide, documented examples show what to check; they are not intended to compare providers or imply that their policies are equivalent.

Microsoft’s official documentation explains that customers can export certain data, including text, audio, image and video files, as well as database content. It also identifies exclusions: information used to configure resources—for example, certain technical settings and resource names—and protected proprietary data such as trade secrets are not considered exportable customer data. The list of exclusions matters as much as the export promise.

This example suggests a concrete check: find the definition of exportable data and read the exceptions rather than relying on a general statement about portability. The documentation reviewed describes content categories and limits, but it does not show that all platforms offer the same options or that every type of data produced by an AI feature is included. The policy must be checked for the specific product, service and information the business intends to use.

You should also check the available formats and whether documentation explains their structure. A familiar format may make processing in other tools easier, but seeing a format name on a commercial page is not enough: what matters is whether the export contains the necessary fields, preserves relevant relationships and can be repeated for a sufficient volume of data. Format, content and procedure are three separate checks.

If the documentation does not clarify a point, record it as an open question rather than resolving it by assumption. Before signing up, ask for a precise answer on whether the provider allows the business to export the specific data it will generate, in what format and through what process. If the answer affects operational continuity, ask for it to be reflected in the applicable contractual commitments.

Retention addresses a different question from portability: how long the service keeps certain data and what happens afterward. Amazon Location Service documentation states that device positions are stored for 30 days before being automatically deleted. By contrast, geofence geometries supplied by the user must be deleted explicitly. The same service may apply different rules to different types of data.

This example should not be generalized to other AWS products or other providers. Its value is to show why each category and operation must be reviewed separately: retention, automatic deletion and deletion that requires customer action are not the same thing. During an assessment, identify what data is stored, for how long, what triggers its deletion and whether the documentation specifies exceptions or additional steps.

For a business, the retention period may affect when it makes sense to export information and how to plan a migration. The deletion policy may also matter for internal management and obligations the organization must meet. However, a technical page for one specific service cannot establish which legal obligations apply to a particular business or what happens to every copy or associated system. That requires reviewing the documents applicable to the service and, where appropriate, obtaining contractual or legal advice.

Before adopting a tool, it is worth writing down questions that public documentation does not answer: what happens when an account is closed, whether there is a period to recover information, how deletion is requested and what its scope is. Do not assume there is a grace period or that deletion is immediate. A lack of a public answer is an information gap that should be raised with the provider before relying on the system.

APIs and integrations can make it easier to exchange information between systems, but their mere existence does not prove that a solution is easy to replace. To assess them, review which operations they support, what data they expose and what limitations the provider documents. Also check whether an integration covers the workflow the business actually uses, instead of assuming that a generic connection will solve migration. A documented interface is evidence of a specific capability, not a guarantee of a complete exit.

The information available for this article does not include API documentation for an AI software product and does not allow a comparison of endpoints, usage limits or compatibility between providers. It therefore cannot support a claim here that a particular API reduces lock-in, or that an AI feature depends on a proprietary or open-source model. Those questions must be checked against the technical documentation for the specific product under consideration.

In practice, the review can be organized around verifiable questions: Is there an official interface reference? Does it describe the data that can be read or changed? Are access conditions or limits published? Are changes and versions documented? If the business needs to keep an integration running, it should also check who maintains it and what commitments apply if the service changes. Answers may vary by product and plan, so a conclusion about one platform should not be carried over to another.

For AI-based features, there is another caveat: an interface may let a user access a feature without providing access to the underlying model, its parameters or a compatible alternative. The available research does not establish which conditions apply to specific products. Access to a feature is not the same as control of its underlying technology. If that control is necessary, confirm it in documentation or a contract rather than inferring it from the presence of an API.

A simple matrix helps separate what is documented, what is inferred and what remains unresolved. For each critical data type or feature, record the official source, the capability it describes, its limits and the question that remains unanswered. This makes the difference between a general promise and a concrete operational instruction visible, and prevents a commercial expectation from becoming an assumed requirement without evidence. The matrix organizes the review; it does not replace a contractual guarantee.

The table is an analytical tool, not a ranking of providers. For example, Microsoft documents exportable categories and exclusions, while the Amazon Location Service page specifies retention periods and a distinction between automatic and explicit deletion for certain data. These are evidence of different scopes: they do not allow a general comparison of the quality of the two services or establish that one is more portable than the other.

Issues that affect business continuity may require explicit commitments: what data will be provided, by when, in what format and for how long access will remain available after the relationship ends. It may also be necessary to clarify who responds to an export request and what assistance is included. Technical documentation helps frame more precise questions; contractual terms determine which obligations have been accepted. Do not turn an expectation into a commitment without written confirmation.

A minimum checklist before deciding can be useful:

• Identify the data and outputs that would be difficult to reconstruct.
• Find the official documentation describing export, retention and deletion.
• Confirm formats, limits and steps through an answer that applies to the specific product and plan.
• Settle essential conditions that are not publicly documented in the contract.
• Keep the version and date of the documents reviewed so that later changes can be identified.

This process does not eliminate lock-in risk, but it helps identify it before the business has accumulated information or processes that are difficult to move.

The evidence reviewed supports limited conclusions: Microsoft states that export options are available for certain categories and specifies exclusions; Amazon Location Service documents a 30-day retention period for device positions and requires geofence geometries to be deleted explicitly. These are useful examples of the details to look for, not a comparative assessment of AI software or a recommendation for a provider.

The available documentation does not provide a sufficient basis for comparing export formats across AI tools, verifying the portability of interaction histories or determining which providers allow configurations, instructions or generated outputs to be migrated. Nor does it establish general conditions for APIs, underlying models, service continuity, price changes or commitments if a provider shuts down. These points should not be presented as established facts without a specific source.

For a small business assessing a tool, the practical decision is therefore to treat portability as a set of verifiable requirements: what needs to be recovered, what is documented, what remains unconfirmed and what must be included in the contract. There is no need to assume that every AI feature is inherently difficult to replace, or that an advertised export resolves the exit process. The prudent conclusion depends on the product, the type of data and the applicable terms.

This article does not provide legal advice or a technical audit of specific services. Documentation can change, and terms may depend on the product, plan, region or contract. Before making a decision, consult the current official sources for the exact service and keep a record of answers to essential questions.