1. Workflow coupling determines the operational risk of a single service
First, separate two ideas. In this article, a ‘tool dependency’ means that a team uses a model, service or API at one point in a task. A ‘workflow dependency’ is the business path created when that tool is joined to data sources, task rules, downstream systems, acceptance criteria and the final decision. The former is easy to see in a procurement register. The latter often appears only when someone traces a real delivery backwards. Confusing the two narrows the discussion to how many model providers have been connected, and misses where risk is actually determined.
A single service is not automatically high risk. If a task merely prepares an outline for an internal meeting, its input files remain inside the organisation, staff judge the output themselves, and a half-day delay changes no customer or business commitment, keeping one tool may be more sensible than maintaining two integrations. Conversely, a team may connect several models yet still have only one practical handover point if original tickets are locked in a proprietary workspace, task rules live only in one employee’s long chat, or downstream systems consume unreviewed output directly. The number of vendors is not a substitute for a risk rating.
Whether a node is critical should be judged by the consequences of interruption, not by its technical novelty. Ask, in turn: which delivery, customer communication or business decision stops if this step stops; whether the input can still be obtained and interpreted as intended; which systems receive the output; who can say that a result must not be used; and what material a person needs to take over. NIST’s AI RMF is a voluntary, non-sector-specific and use-case-agnostic risk-management framework. It lists, among the outcomes an organisation may adopt, mapping system components and internal controls—including third-party software and data—and preparing contingency or incident procedures for third-party data or AI systems judged to be high risk. [1]
Such a framework does not define a ‘critical workflow’ for an organisation. It does, however, offer a useful lens: an external model is one component of a system, while risk arises from the way components are connected. The NIST AI RMF Playbook likewise notes that third-party resources can improve efficiency and scalability while adding complexity and opacity; documenting the technologies, people and resources in use makes those dependencies manageable. [2] The unit of audit is therefore better understood as the complete process from task trigger to business acceptance of the result, rather than a service name or a subscription invoice. That is a working method inferred here from risk mapping, not NIST’s formal definition of a workflow dependency.
Consider a company that uses AI to handle customer tickets. A ticket arrives; the system extracts its text and the customer-account context; the model produces a summary and suggests a handling category; a customer-service supervisor checks high-risk cases; then a business system creates a draft response. If the model service is temporarily unavailable, the real question is not whether another model can answer the same prompt. It is whether the ticket text can be exported; whether account context has a readable source; whether the summary format is documented; whether the supervisor can see a queue awaiting review without the old interface; whether draft creation can be paused; and who decides when automation resumes.
The example also shows how dependencies propagate in different directions. At the input end, the risk is that material cannot be obtained, field meanings are unclear, or no one has defined what may be submitted. In processing, rules may be buried in prompts, scripts or proprietary tool calls. At the output end, result formats may be coupled to downstream interfaces. In decision-making, human review may appear to exist but lack a clear owner, time window or authority to stop automation. Any one of these can turn ‘switching models’ into a process-redesign project rather than a simple parameter change.
When auditing, it helps to break down the question of whether people can do the work manually. Human takeover is not simply asking someone to read the original text temporarily. It includes whether they can obtain sufficient context, whether usable business rules exist, who confirms the result, how a conclusion is written back to downstream systems, and which actions must wait until review is complete. If a manual path exists only in conversation, it will still be blocked at the critical moment by missing information, inadequate access or unclear responsibility. Conversely, a functioning manual path does not mean automation is never needed; it provides a testable floor for an important workflow.
This suggests a more practical way to classify work. For tasks with low impact that can be delayed or easily made good, a high degree of dependency on one tool may be acceptable; retaining inputs and instructions is the priority. For workflows that send customer notices, change business records, affect compliance review or compress room for human judgement, the end-to-end path should be audited first, with fallback, review and suspension conditions made explicit. This article does not argue for one recovery-time target across every situation. Risk tolerance and investment should follow the consequences of the workflow, not the fame of a particular model.
2. Organisation-controlled inputs, rules and acceptance criteria are portable assets
Making a workflow portable does not mean copying a prompt into another service. A prompt may be part of a task, but it is rarely a complete task definition. What an organisation needs to retain is the material that lets another employee, another implementation or a manual path understand the business intent: where inputs come from, which content may be processed, what problem is to be solved, what output is acceptable, who decides on exceptions, and how a traceable record is retained. Without these elements, migration usually amounts to carrying an old habit into a new interface.
It is useful to regard this material as a task package rather than a technical specification. A task package should distinguish at least four layers. First comes the input contract: data sources, field meanings, the scope of material allowed into the model, and how missing or conflicting information is handled. Second are task rules: the judgements to be made, business constraints to observe, priorities and cases that should not be handled automatically. Third is the acceptance contract: output structure, facts that must be checked, conditions requiring human escalation, and results that should be rejected. Fourth is the record of responsibility: the workflow owner, approver, exception handler and the person responsible for updating the material after a change.
The value of these layers is not the number of documents. It is that they separate ‘why we do this’ from a particular supplier’s implementation details. A ticket-classification rule, for example, can say which cases must go to a person and which missing fields preclude automatic classification, rather than preserve only wording that tells a model to emit a particular label. What a downstream system needs is a controlled category and a reason field, not the narrative style of a particular model. Models, prompt forms and tool calls can then change while the business layer retains an inspectable objective.
This layering is consistent with the governance approach in the NIST framework. The framework lists inventories of AI systems, safe decommissioning, human–AI configurations and oversight responsibilities, and risk mapping of third-party components as governance or mapping outcomes. [1] For an organisation, that means recording more than the model in use. It should be able to identify where the model participates in a decision, who supervises it, which data and systems it connects to, and which business steps must survive if it is retired or replaced. Treat an inventory as an asset catalogue and it can become very long; treat it as a map of responsibility and takeover, and it gets closer to recovery capability.
Acceptance material cannot be left solely on the model side either. A portable process should keep a small set of representative samples, known failure modes, the structure of an acceptable output and human decision rules where the team can maintain them. These samples do not prove that a model is ‘smart enough’. They expose task boundaries: omissions that make an output fail, cases that must be sent to a person, and outputs that may read fluently but must not enter a downstream system. In its MEASURE function, NIST lists records of pre-deployment and in-operation testing, test sets, metrics and tool details, together with monitoring of functions and behaviour in production, as relevant measurement outcomes. [1]
That does not mean every workflow needs a large evaluation platform. For a low-risk internal collation task, a few samples that represent common errors, a clear human checkpoint and an input description may be enough. For a process affecting customers, money, compliance or a critical delivery, acceptance samples and escalation conditions should be stricter and should not be defined solely by the person who originally built the automation. The point is to match testing to task consequences, not to mechanically impose one template on every situation.
Three tests can help decide what should be portable first. First, does it express the organisation’s own business intent? If so, rules and approval conditions should not exist only in a vendor interface. Second, is it necessary for independent acceptance? Without input sources, output definitions and samples, a team cannot tell whether an alternative works. Third, does it determine whether a person can take over? If an instruction is understood only by the old system, it becomes a bottleneck on migration day. By contrast, a model-specific parameter, formatting trick, proprietary tool call or interface operation may be recorded, but it belongs more naturally in the adapter layer and should not be mistaken for a business rule.
‘Portable’ does not mean that everything should be copied. Model phrasing, reasoning paths, proprietary retrieval chains, multimodal capabilities and tool-collaboration patterns can differ. After a replacement, some capabilities may have to be degraded to a narrower automation scope, subject to more human review, or suspended in specific situations. Writing those limits into the task package in advance prevents a team from discovering on the day of change that the original process relied on a capability that cannot be reproduced equivalently. For important tasks, an honest degradation plan is usually more useful than a promise of seamless substitution.
A task package is not a one-time archive item. Changing input sources, updated business rules, renamed downstream fields and transferred approval responsibilities all make old material gradually inaccurate. NIST’s Generative AI Profile stresses that risk management should reflect the specific context of use, risk tolerance and resources, and extend across the system lifecycle. [3] A better maintenance method is to attach updates to actual workflow changes: check the input contract when a data source changes; revisit acceptance conditions when the automation scope changes; confirm takeover responsibility when people or permissions change; and rerun relevant samples when models or integrations change. The purpose is not to maintain documentation for its own sake, but to keep it aligned with real work.
3. A backup supplier becomes contingency capability only after testing
Many teams treat connection to a second service as proof of fallback capability. In practice, they often have only an unused connection. Candidate vendors, pinned model versions, compatible interfaces and local adapters can shorten the time needed for experiments, but they do not automatically prove that the original workflow can continue. To decide whether they constitute contingency capability, return to business acceptance: under the same input constraints, output definitions and human responsibilities, can the alternative path complete the current task? The test is not whether it can generate text that looks similar.
Replacing a model cannot be reduced to changing a name because the behaviour itself may change. OpenAI’s API documentation says that prompt behaviour may change between model snapshots, model output is inherently variable, and applications should pin model versions and run evaluations. [4] Pinning a version can bind an evaluation to a definite object, but it cannot turn model output into a static guarantee. When the task, input, integration or business standard changes, the team still needs to judge whether the evaluation covers the new risk.
Models and interfaces also have their own lifecycles. Anthropic’s official documentation records model retirements and cases in which parameters are deprecated or behaviour changes. [5] That is what the public documentation describes for that service, and cannot be generalised as a policy shared by every supplier. OpenAI’s documentation likewise describes only its own interface commitments. Their relevance here is not to predict the date of the next change, but to remind a team that a particular model, parameter combination or proprietary capability embedded in a critical workflow should be treated as a condition that needs managing, not as fixed background.
Supplier substitution also encounters finer differences. An alternative path may receive the same text yet not support the same tool calls; it may produce similar fields but need a different instruction structure; or its output may be readable by a person but unsuitable for direct entry into an existing downstream interface. An organisation need not chase superficial consistency across these differences. It should first define a minimum acceptable service: which critical fields must be complete, which facts must be checked, which inputs must not be processed automatically, and which actions must wait for human approval. Only when that business floor is clear can a technical team know what the adapter layer has to solve.
A meaningful fallback exercise runs the whole task. A team can select approved or de-identified samples and start with input acquisition, then proceed through the candidate service, output parsing, human acceptance and downstream writing, until the result is accepted or rejected by the business. The key checks are not whether the answer resembles the old model’s answer. They are whether critical fields are complete, fact-checking can still be performed, exceptions reach a human queue, a downstream system will mistakenly treat a draft as a conclusion, and recovery time falls within what the workflow can bear. NIST treats testing, evaluation, verification and validation before deployment and during operation as continuing risk-management activities, and includes records of the relevant methods and results within measurement activities. [1]
Exercise outcomes should not be divided only into ‘success’ and ‘failure’. If an alternative service produces an acceptable draft but substantially increases human review, the team can define it as a degraded mode rather than normal automation. If it handles only structured inputs, its scope should be limited. If critical facts cannot be accepted reliably, the process should stop at a human node rather than keep writing to downstream systems for the sake of throughput. These decisions turn reliability from an abstract technical property into an explicit trade-off about business consequences.
A backup path has costs as well. Parallel connections increase the burden of maintenance, access management, testing and allocation of responsibility. For some low-criticality workflows, maintaining a second system indefinitely may not be more economical than an exercised manual path. For high-impact workflows, by contrast, waiting until a service changes to test the fallback may mean the window of control has already been lost. There is no universal rule requiring two suppliers. A sensible choice depends on interruption consequences, the acceptable amount of human work, what testing has established about the alternative path, and how much complexity a team is prepared to maintain.
4. Dependency audits should allocate effort by business criticality
Listing every AI tool in an asset register produces a procurement list, not recovery capability. A smaller, usable starting point is a workflow card for each important process. It need not imitate a complex compliance form, but it should answer basic questions when a change or interruption occurs: what business purpose the process serves; who bears the consequences of interruption; which inputs, suppliers and downstream systems it relies on; where the task package sits; what tested alternative or manual path exists; who can approve exceptions and stop automation; and which residual risks the most recent exercise revealed.
The value of a workflow card is that it puts different roles on the same map. A business owner can explain which consequences are unacceptable. Data or systems owners can identify the inputs and interfaces. A process owner can maintain task rules. A reviewer can set acceptance boundaries. On-call or operations staff need to know whom to notify and which action to pause first when degradation is triggered. Without this allocation of responsibility, a technical team may prepare several APIs yet still be unable to decide when to switch, or who may accept a poorer but usable result.
Take the customer-ticket example again. An audit should not end at ‘which model do we call?’ The workflow card can record where ticket text comes from, which system supplies account context, which material may be viewed only by people, which suggested fields the model produces, when a supervisor must review, how a draft response enters the CRM, and how tickets are kept from being forgotten after automation is paused. It can then ask whether staff can use the original text and a fixed template for first-line handling if the model is unavailable; whether degraded classification can retain only summaries and disable automatic routing; and whether results can first enter a queue rather than formal records if the downstream interface changes. This breaks the question of supplier replacement into five discussable decisions: inputs, rules, acceptance, interfaces and responsibility.
That leads to practical investment choices. If the manual path is complete, input material is available, the task package is clear and the consequence of interruption is acceptable, an organisation can retain a single service and concentrate on monitoring and exercises. If inputs and rules can be retained but the alternative path is untested, the priority is to fill in samples and fallback testing rather than promise permanent active-active operation immediately. If a workflow directly affects customers, compliance judgements or irreversible business actions and has no acceptable manual takeover, the problem is not merely supplier concentration: the scope of automation itself may need narrowing. There is no universal answer. The workflow card makes trade-offs visible; it does not make the management decision automatically.
Lifecycle maintenance should begin with the question of when to re-audit, not how often to complete a form. Triggers can include a change in input source, business rule, model or parameter; an added tool call; a downstream-system redesign; a change in approval responsibility; or a newly exposed failure mode in an exercise. Each trigger need not require a full redesign, but it should prompt a judgement about which task packages, samples, adapter layers and manual paths no longer represent reality. Binding audits to change reduces the risk that a document continues to be treated as reliable after the workflow has changed.
NIST’s CSF 2.0 quick-start guide recommends identifying technology suppliers and judging their criticality, defining responsibilities and requirements, and including relevant suppliers in incident planning, response and recovery. [6] The guide addresses cybersecurity supply chains directly, not AI workflows. Applying it to AI-service dependencies should be treated as a limited reference for managing external dependencies by criticality, not as a ready-made answer to AI compliance. Its lesson is that supplier management should not take place only at procurement; it should also cover changing criticality during the relationship, incident response and recovery arrangements.
The AI RMF’s management outcomes also include preparing failure or incident procedures for high-risk third-party systems and prioritising responses by impact, likelihood and available resources. [1] Applied to the workflow card in this article, that reasoning means an organisation need not redesign every tool at once. It can start with a process whose interruption for a day would noticeably affect customers, compliance or delivery; audit its inputs and responsibilities; then run a fallback exercise. Based on the remaining risks the exercise exposes, it can decide whether to add an alternative service, strengthen a human queue, separate a downstream interface or narrow the automation’s decision scope.
Ultimately, not betting an important workflow on one AI tool does not mean turning everything into interchangeable parts. Model capabilities, tool ecosystems and output styles genuinely differ, and flattening those differences may not be worthwhile. The question is whether the organisation retains the inputs and rules needed to do the work, can accept results independently, can carry responsibility when necessary, and has tested a degraded path before change arrives. Portability is not a product label. It is a maintained and verified property of a workflow. It cannot eliminate model errors, supplier changes or external interruptions, but it can prevent an organisation from quietly handing its ability to recover to one tool.
