AI Glossary / Governance, ethics and safety / Intermediate

Dependability

Definition

Dependability is the ability of a system to provide a service that people have sound reasons to rely on. It concerns whether failures occur with an acceptable frequency and severity in the intended circumstances. For an AI service, dependability involves the whole working arrangement: the model, software, data, people, dependencies, and recovery procedures.

What it means

A dependable assistant must do more than produce impressive answers during a demonstration. It needs to work adequately when users need it, handle foreseeable problems, and avoid failures whose consequences are unacceptable. What counts as adequate depends on the task. A delayed suggested email and an incorrect instruction in an industrial workflow have different consequences. Dependability therefore needs a stated purpose, operating conditions, and acceptance criteria. It is a reasoned claim supported by evidence, rather than a synonym for confidence, popularity, or a friendly interface.

How it works

Teams begin by defining the service and identifying ways it could fail. They prevent faults where practical, detect problems, contain their effects, and provide recovery or fallback options. Testing, operational monitoring, and incident investigation supply evidence about performance under relevant conditions. A classic computing taxonomy brings together availability, reliability, safety, integrity, and maintainability within dependability. These attributes overlap but are not interchangeable. An AI endpoint can remain reachable while returning corrupted information, and a highly accurate model can be unavailable when its database fails. The evaluation boundary should include the components and human actions needed to deliver the actual service.

Three practical examples

• A customer-service assistant switches to a clear handoff process when it cannot retrieve the current policy, instead of improvising an answer.
• A document-processing workflow validates extracted totals and routes inconsistent records to review before they reach a payment system.
• An internal search service rehearses restoration after a failed index update and measures whether staff can resume useful work. Each example addresses a particular failure mode rather than claiming universal dependability.

Think of it this way

Think of a dependable elevator. People rely on more than whether its motor usually runs: doors, controls, maintenance, emergency behavior, and inspections matter together. The analogy is limited because AI tasks often have less sharply defined correct outputs and more changing inputs. It still highlights why confidence in one component is insufficient. A service deserves reliance only when its overall behavior and failure handling are suitable for its purpose.

Worked example

Suppose an assistant is scheduled to serve users for 1,000 minutes during an observation period. It is unavailable for ten minutes, giving a simple observed time availability of 990 divided by 1,000, or 99 percent. During its available time, it processes 2,000 independently reviewed requests, of which 1,960 meet the task criteria: a 98 percent observed success rate on those requests. Neither figure alone establishes dependability. The forty unsuccessful requests might be minor formatting errors or serious incorrect instructions. The ten unavailable minutes might occur during a critical deadline. The team therefore records failure types, consequences, and timing alongside the rates. It also checks whether the observation period represents expected use. These are descriptive measurements, not a guarantee that future performance will match them or a justification for multiplying the percentages into a universal dependability score.

Illustrative case study

Fictional case: Rowan Logistics pilots an assistant that summarizes shipment exceptions. Early testing emphasizes summary accuracy. A later exercise finds that a stale tracking feed can produce confident but outdated summaries even while every server appears healthy. The team adds freshness checks, displays the last confirmed update, and provides a manual escalation route. It then tests the complete workflow with delayed and missing feeds. The case illustrates how a service boundary changes what must be checked; it does not claim a measured improvement from a real company.

Common misconceptions and mistakes

Dependability does not mean a system never fails. It means the evidence and failure behavior meet requirements appropriate to the reliance placed on it. High uptime is not proof of correctness, and high benchmark accuracy is not proof of operational availability. Redundant components can share the same defect or faulty data, so duplication does not automatically remove risk. A human reviewer also helps only when that person has suitable information, time, authority, and competence. Finally, a dependable service in one setting may need fresh evaluation after changes to users, tasks, models, or dependencies.

Business use

Specify the decisions and workflows that will depend on the AI service, including the consequences of delay or incorrect output. Agree on task criteria, response expectations, escalation responsibilities, and recovery needs before launch. Keep evidence tied to the deployed version and environment. Review serious failure modes separately from average performance so that rare but consequential problems are visible. Include support and maintenance capacity in procurement discussions: an unsupported component can weaken an otherwise capable service. Revisit the claim when the operating conditions change rather than treating approval as permanent.

People also ask

Is dependability the same as reliability?

Reliability is usually one contributing attribute, concerned with continuity of correct service over time. Dependability is broader.

Can a model alone be evaluated for dependability?

Some component properties can be evaluated, but claims about a delivered service require attention to its surrounding system.

Does a dependable service need perfect predictions?

Not necessarily. Appropriate uncertainty handling, review, and safe fallback can be part of an acceptable service, depending on the task and consequences.

Check your understanding

A chatbot has excellent response accuracy in a test but stops working whenever its document store is offline. Does the accuracy result establish dependable service?

Answer: No. The dependency failure affects the delivered service, so availability, fallback behavior, and the intended operating requirements must also be evaluated.

Related terms

• Reliability
• Availability
• Resilience
• Fault tolerance
• Integrity
• Safety
• maintainability
• service failure
• recovery
• assurance

Learn next

Map one AI workflow from input to final action. For each dependency, identify one plausible failure and the user-visible consequence. Choose a controlled test that checks whether the proposed detection and fallback actually preserve the required service.

More in Governance, ethics and safety

• Declarative bias
• Deepfake - A deepfake is synthetic or manipulated media created with deep-learning techniques that can make a person or event appear to be something it is not.
• Denial-of-service - Denial-of-service, commonly abbreviated DoS, is the prevention of authorized access to a resource or a delay that makes required operations unavailable when...
• Deployment Bias - Deployment bias arises when the way an AI system is actually used differs from the role or context for which it was designed and evaluated, creating...
• Detection Bias - Detection bias is a systematic distortion caused by differences in how outcomes are noticed, measured, or classified across groups.
• Deterministic algorithm - A deterministic algorithm follows rules that produce the same result whenever it starts with the same complete inputs and state.

Sources

Avizienis, Laprie, Randell, and Landwehr, Basic Concepts and Taxonomy of Dependable and Secure Computing, original author-hosted paper: https://www.landwehr.org/2004-aviz-laprie-randell.pdf NIST AI Risk Management Framework: https://doi.org/10.6028/NIST.AI.100-1

Previous: Dental sound Next: Dependability state model