What happens if a cloud AI provider is unavailable?

The fallback depends on the job

Two models may both produce useful summaries but behave differently on extraction, classification or a tightly formatted output. Glivent only uses a fallback model after testing it against the same real examples and acceptance checks as the primary model.

If no compatible fallback meets the requirement, the safer response is to pause the affected step and notify staff. The workflow should not send poor output into the next business system simply to remain active.

Options for a cloud-dependent step

An approved design may:

• switch to another tested cloud provider;
• use a suitable model on the Glive Pod;
• continue the non-AI parts of the workflow and queue the cloud step; or
• stop at a clear review point and ask a staff member to complete the task.

The workflow records what happened so staff can see which route ran and what still needs attention.

What can continue onsite

Glive Hub, Glive Flow and the rest of the Glive System continue to run on the onsite Pod. A cloud-model incident does not automatically stop local rules, forms, records, approvals or Private AI tasks.

The practical effect depends on how much of that workflow relies on the unavailable provider. Glivent identifies that dependency during design rather than discovering it during an outage.

Reliability without an absolute promise

Provider fallback improves resilience, but a workflow can still be affected by internet access, connected business software, local hardware or a shared dependency between providers. Glivent documents those dependencies, monitors the managed system and resolves faults within the agreed service.