For an AI workflow your business relies on, identify the service behind it and decide what the team should do if it becomes unavailable or no longer works as expected. Put that responsibility into the ongoing plan before the workflow becomes hard to work without.
Name the dependency in business terms
Start with the task, the people using it and what happens to the business if it stops. Then identify the model or service, the account used to access it and any other connected systems.
A short record should answer:
- What work depends on this service?
- Who uses the result, and who reviews it?
- Which information and connections does it need?
- Who receives account, billing or product-change notices?
- Who decides whether a change is acceptable?
Keep the description useful to the person responsible for the business process, as well as the technology team.
Choose an appropriate way to continue
Discuss the response to a service interruption. Depending on the work, the practical choice might be a manual process, a pause while someone reviews the situation or an alternative service that has already been evaluated.
Do not treat another model as an automatic replacement. Ask what would need to be checked: the result it produces, access to information, connection to other systems and the way employees use it.
The fallback should fit the business task. A workflow that drafts an internal note and one that starts an action on another system need different discussions about review and approval.
Check changes before relying on them
Agree who reviews a proposed change, how it will be tried against representative work and who decides it is ready for use. Keep a way to report unexpected behavior and to pause the workflow when necessary.
NIST’s AI Risk Management Framework includes ongoing monitoring of third-party resources and deployed models. Its guidance supports treating risk management as continuing work across the life of an AI system. See NIST’s AI RMF Core.
The scope and frequency of that work should reflect the actual workflow and agreed responsibilities.
Include continuity in the managed relationship
Managed AI provides ongoing support, governance and improvement for up to 3 standard workflows. Discuss the dependencies, change handling and support boundaries for the workflows in your proposed scope.
New systems, major workflows and substantial integrations need separate scope. Review the effect of a model or connected-system change before deciding how to scope it.
A recurring Managed AI relationship can stand independently of Fully Managed IT. See AI Adoption for how review, launch and ongoing management fit together.
Frequently asked questions
Do we need a second AI provider for every workflow?
Decide from the business impact and a tested plan. A manual alternative or a controlled pause may be more suitable than another provider for some work.
Does running a model locally remove every dependency?
Review the complete arrangement, including its hardware, software, information and support. Evaluate the actual fallback rather than assuming a hosting choice answers every continuity question.
Is fallback design included in Managed AI?
Confirm the responsibility and scope for the proposed workflow. New systems or substantial integration work need separate scoping.
Plan for the work your business relies on
Which AI-supported work would be hardest to pause? Start there, then discuss continuity and ongoing responsibility for the workflow.