Trace the service
Start with a real use case and map inputs, processing, models, tools, data, outputs and human approvals.
GUIDE / PROTOCOL
Map AI system dependencies
An AI service is more than its model: continuity also depends on data, interfaces, people and contracts.
Direct answer
How should an AI dependency be assessed?
Describe the chain that delivers the service, assign an owner to each component and simulate failure or replacement. A risk becomes actionable when its effect, detection time and fallback are explicit.
01 / Review method
Review method
Qualify dependencies
Record vendor, exchanged data, contractual jurisdiction, cost, quota, version, substitutability and internal owner.
Test disruptions
Simulate outage, price change, answer degradation, API withdrawal or failed export.
Choose a fallback
Define alert thresholds, degraded mode, backups, export, tested migration and an authorized stop decision.
Reading workshop
Storage location does not describe the whole journey
The DEMO diagram is a hypothetical architecture, not an observed supplier inventory. Flows are assumptions to document.
Fictional data and records for learning: none of these results comes from a live service query.
Follow the copy in the logs too
Tool T selects a catalogue passage for model P. The orchestrator is intended to retain an output in B and a technical trace in L. The design names a location for B but not L.
If the table exceeds the screen, scroll horizontally; arrow keys work when the region is focused.
| DEMO component | Planned flow or copy | Possible failure effect | Missing evidence |
|---|---|---|---|
| Model P | Selected passage sent for drafting | Generation may be blocked | Processing terms and interface scope. |
| Tool T | Catalogue read before generation | An inaccessible source may prevent a supported answer | Data freshness and behaviour without the source. |
| Log L | Trace may contain input and output | The task may work while leaving an unmanaged copy | Recorded fields, access and retention duration. |
| Storage B | Retained output, zone A stated in the plan | An outage may block dossier delivery | Configuration, read rights and recovery copy. |
What follows from zone A being stated for B?
Open each proposition to compare its diagnosis. More checks may still be needed.
All processing and logs remain in zone A
No. B’s location describes neither P, T nor L. Trace every flow and copy.
Replacing P alone makes the fallback independent
No. T, L, B or authentication may remain shared. Replacing one node does not isolate the whole chain.
It describes only part of the design
Yes. Separate assumptions, configurations to obtain and tests to perform before describing operation.
Fictional text flow map
T → P: DEMO catalogue passage P → orchestrator → B: planned output Orchestrator → L: planned technical trace B: zone A stated in the design L: location, fields and retention undocumented Access: check B and L rights separately State: hypothetical architecture, no test performed
Letters denote invented technical roles. An arrow is a planned flow here, not a measured transfer or system certification.
Documentation of the rules, separate from fictional examples
02 / Evidence to keep
Evidence to keep
Flow map
Dated diagram of components, data boundaries and human interventions.
Vendor register
Contracts, versions, quotas, costs and exit conditions verified at audit time.
Replacement trial
Export and substitute test results, including quality and cost differences.
Continuity plan
Thresholds, owners, manual or alternative mode and acceptable recovery time.
Compare other situations and exercises
PRACTICAL CHECK
Before reaching a conclusion
A frequent misreading and the check that helps avoid it.
Premature conclusion
A supplier list alone does not describe dependency. A model change may affect quality, cost, usage rights or recovery.
Decisive check
Trace data flows and calls to each supplier, then test export, replacement and service shutdown. Name an owner for every critical dependency and its review frequency.
AFTER THE REVIEW
Decide from the evidence
One vendor holds both data and execution
Identify what cannot be exported or replaced. Prepare usable copies, degraded operation and a substitution trial before rating the risk.
A dependency has no owner
Name an owner, alert threshold and fallback action. A map without decision or test does not prove an exit capability.
Decision and review trail
Decision and review trail
What the check must help decide and what to retain so the choice can be reviewed.
Sufficient evidence
For every critical dependency, record owner, exposed data, export format, exit cost and restoration test. A contractual promise does not replace a tried export.
Next decision
Prioritise exits that are impossible or slow, with an owner and next test date. Retain useful dependencies whose risk is measured.
Detailed inspection cases
Typical situations for preparing a check. They do not describe completed assignments or actual observations.
The export loses references
What to inspect
Export a trial record and compare text, files, links, identifiers and history with the original.
Decision and action
Describe losses before declaring an exit viable; arrange transfer of missing records.
Record to retain
Before/after inventory, lost fields and recovery procedure.
Two interfaces share a provider
What to inspect
Identify upstream services behind interfaces presented as fallback options.
Decision and action
Test failure of the shared dependency; diversify the critical component when the fallback also relies on it.
Record to retain
Flow map, shared dependency and exercise outcome.
Fallback depends on the same vendor
What to inspect
Compare models, networking, storage and authentication for primary and fallback services.
Decision and action
Identify shared dependencies before calling the fallback independent.
Record to retain
Shared components, failure trial and tasks still possible.
Review before deciding
These questions complement the method. They help establish what is actually supported while retaining qualifications in the record.
Whole dependency chain
Does the record cover model, retrieval, tools, hosting, logs and known subcontractors? For each output, specify what actually leaves the boundary.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- The diagram names model and hosting; retrieval service and logs have no identified owner.
- Declared state
- Not checked
- Decision and next check
- Keep these dependencies open and identify outgoing data, operator and access before validating scope.
Tested exit
Have a useful export and recovery outside the provider been tested with test data? A downloaded archive without restoration or reading does not demonstrate reversibility.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- A test archive was obtained internally; its content could not be read in the recovery tool.
- Declared state
- Observed discrepancy
- Decision and next check
- Exit remains unproven. Fix format or recovery path, then check retained relationships and rights.
Necessary permissions
For each tool, do granted permissions match expected operations? Record unnecessary privileges without collecting secrets in the map.
Documentation consulted : OWASP · Excessive Agency ·
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- The test-scenario inventory confirms document reading with no tool able to act on an external service.
- Declared state
- Justified exclusion from scope
- Decision and next check
- Justify excluding action permissions for this version. Reopen when a connector or write tool is added.
TOOLS / REGISTERS
Information to record
Test access withdrawal or unavailability in a controlled scope. Document what stops, what continues and recoverable data before calling a fallback operational.
- Access date and time zone
- Exact URL
- Component / provider
- Data / permissions
- Tested fallback
- Review owner
- Decision / next action
- Next review
03 / FAQ
Frequently asked questions
Must everything be self-hosted?
No. Decide from the data, required control, skills, cost and ability to exit.
What makes a dependency critical?
Failure or change blocks an essential outcome with no acceptable fallback.
How can reversibility be tested?
Export data and configuration, rebuild a minimum journey elsewhere and measure the gaps.
Who owns the register?
Business and technical owners should both be able to read, update and act on it.
Is an alternative enough to remove a dependency?
It reduces a dependency when a transfer is feasible and verified. Formats, skills, contracts and behaviour can create other constraints that must remain visible in the recovery plan.
04 / Official references
Official references
Describe a context
DEEPER READING / PRACTICE
Identify an AI system’s dependencies
A system combines model, hosting, tools, data and integrations. The map must show the elements whose unavailability or change may interrupt an essential use.
Updated on .
Priority checks
Inventory suppliers, formats, access, known limits and replacement possibilities. Relate each dependence to the assigned tasks and the information needed to a recovery.
Interpretation pitfalls
Having a second supplier does not guarantee an immediate replacement. Differences in formats, behavior and permissions may require adaptation and new assessment.
Working record to retain
The dependency card combines component, use, stop-effect and planned recovery solution. Replacement assumptions must be verified on a specific case.