Updated 17 October 2026. This article has been revised to separate the policy timeline from the product argument. See the current AI Act timeline for the category-specific dates and primary reference.
A governance plan has dependencies. Some belong to the team, some to suppliers and some to the wider regulatory environment. Treating all of them as someone else’s problem makes the plan impossible to manage.
Name the dependency and its fallback
For each important control, identify what it depends on. A supplier may provide model documentation. An internal team may maintain identity records. A reviewer may need access to a test environment. Each dependency should have an owner and a way to notice when it is not available.
Consider an illustrative evaluation that relies on a supplier version remaining stable. If the supplier changes the model, the previous result may no longer describe the deployed configuration. The team needs a change signal and a decision about retesting.
Where a dependency cannot be guaranteed, record the fallback. That may mean restricting a feature, changing the deployment or accepting a clearly bounded uncertainty through the appropriate process. The fallback should be feasible, not a sentence copied from an incident template.
Review dependencies before increasing autonomy. More tool access can create new dependencies on external services, approval systems and recovery procedures. A capability diagram that omits those relationships is incomplete.
| Decision | Evidence to request |
|---|---|
| Dependency | Required input or service |
| Failure signal | How unavailability becomes visible |
| Fallback | Feasible response and responsible owner |
What to do with this
The useful plan is the one that explains what happens when a dependency fails. Everything works beautifully in the version where every other team is magically on time.
Record the decision, the responsible owner and the evidence still missing. The decision-record example shows a lightweight way to do that. Where a claim concerns system behaviour, connect it to evaluation evidence. These are proposed product practices, not a finding that a system complies with the law.
Primary timeline reference: European Commission, AI Act. The operational recommendations above are my analysis.
