7.3 A.4 Resources for AI Systems
Key Takeaways
- A.4 requires identification and documentation of resources that AI systems depend on: overall resource documentation (A.4.2), data resources (A.4.3), tooling (A.4.4), system and computing resources (A.4.5), and human resources (A.4.6).
- Clause 7.1 resources and Clause 7.2 competence connect to A.4: Annex A makes AI-specific resource categories explicit and auditable per system or system class.
- Lead auditors sample resource adequacy for high-risk systems—not merely a corporate GPU budget line—looking for inventory, ownership, capacity, and competence fit.
- Human resources under A.4.6 include roles that develop, operate, oversee, and govern AI; skill matrices and training records should match assigned authorities.
- Common NCs: no resource inventory; production models with unknown training-data hosts; shared admin tooling without ownership; high-impact systems staffed only by contractors with no competence evidence.
7.3 A.4 Resources for AI Systems
Auditor focus: AI systems fail when nobody can answer “What data, tools, compute, and people does this model depend on—and are they adequate?” A.4 is your structured inventory and adequacy test, especially for high-risk systems.
Control objective (intent): Ensure resources necessary for AI systems are identified and managed so the organization can develop, operate, and improve AI responsibly within the AIMS.
A.4 is AI-specific resource control. It complements Clause 7.1 (Resources) and Clause 7.2 (Competence) but is not satisfied by a generic “IT has a budget” statement.
A.4 Control Map
| Control | Name | Core expectation | | :--- | :--- | | A.4.2 | Resource documentation | Document resources associated with AI systems (as determined necessary) | | A.4.3 | Data resources | Identify and document data resources used for AI systems | | A.4.4 | Tooling resources | Identify and document tools used to develop, operate, or manage AI systems | | A.4.5 | System and computing resources | Identify and document system/computing resources supporting AI systems | | A.4.6 | Human resources | Identify and document human resources (roles/competencies) needed for AI systems |
Together these five controls force visibility. You cannot govern what you cannot name.
A.4.2 Resource Documentation
A.4.2 is the umbrella: resources relevant to AI systems are documented at a level that supports operation, risk treatment, and continuity.
Strong evidence:
- Per-system or per-system-class resource sheets linked to the AI inventory
- Ownership, location (cloud account/region), dependencies, and update cadence
- Links from resource docs to risk treatment, impact assessments, and runbooks
Weak evidence:
- One corporate architecture diagram with “AI stuff” as a cloud icon
- Spreadsheets last updated at go-live two years ago
- Documentation only for marketing demos, not production decisioning systems
Auditor sampling method:
- Select 2–3 systems from inventory (bias to high impact / recent change).
- Request resource documentation package.
- Spot-check three claims (e.g., dataset path, training cluster, on-call owner) against live config or interviews.
- Ask how documentation is updated after retrain, vendor change, or scale-out.
A.4.3 Data Resources
Document what data the AI system relies on—for development, evaluation, and operation as applicable:
| Dimension | Examples to verify |
|---|---|
| Sources | Internal warehouses, licensed datasets, third-party APIs, user-generated content |
| Categories | Personal data, special categories, synthetic data, embeddings stores |
| Roles of data | Training, validation, test, fine-tuning, RAG corpora, feature store, feedback loops |
| Constraints | Licenses, retention, residency, consent limitations |
| Owners | Data stewards vs model owners |
Note: Deeper quality and provenance obligations appear under A.7. Under A.4.3, first confirm the organization knows and records which data resources exist. Missing data inventory often co-occurs with A.7 and privacy gaps.
Scenario: A recruitment ranking model uses a vendor embedding API and an internal résumé store. Resource docs list only “HR database.” The embedding vendor and prompt/log stores are invisible. Raise A.4.3 (and likely A.10/A.7) for incomplete data resource identification.
A.4.4 Tooling Resources
Tooling includes frameworks, platforms, and services used to build and run AI:
- ML frameworks and experiment tracking
- Feature stores, labeling platforms, evaluation harnesses
- CI/CD / MLOps pipelines, model registries
- Monitoring/drift/fairness tools
- Generative AI platforms and IDE plugins used in scope
Probes:
- Is use of shadow tools (personal ChatGPT accounts, unmanaged notebooks) controlled?
- Who administers the model registry and who can promote versions?
- Are evaluation tools version-pinned and access-controlled?
Trap: Claiming “we use Python” as the entire tooling inventory for a regulated production system.
A.4.5 System and Computing Resources
Cover infrastructure that training, inference, storage, and networking depend on:
| Resource class | Audit questions |
|---|---|
| Compute | GPU/CPU capacity for training and peak inference; autoscaling limits |
| Environment separation | Dev / test / prod isolation for models and data |
| Storage & bandwidth | Dataset and model artifact storage; latency paths |
| Resilience | Failover, multi-region needs for critical services |
| Constraints | Cost caps that silently degrade monitoring or retraining |
Adequacy is risk-relative. A research sandbox may accept limited compute. A 24/7 clinical decision support service that loses monitoring because “GPU budget was cut” shows A.4.5 (and performance evaluation) stress.
Sustainability / capacity: Where the organization commits to environmental or capacity objectives, resource docs should not contradict operational reality—but do not invent ISO 42001 “carbon control numbers” that the standard does not prescribe. Stick to documented resource identification and adequacy for intended performance and risk treatment.
A.4.6 Human Resources
Human resources for AI systems include people who:
- Design and train models
- Label and curate data
- Operate MLOps and monitoring
- Provide domain expertise and human oversight
- Own risk, compliance, and AIMS governance
Evidence patterns:
| Artifact | What it shows |
|---|---|
| Role descriptions / RACI linked to systems | A.3.2 + A.4.6 connection |
| Competence criteria & skill matrix | Fit for high-risk tasks |
| Training / certification records | Clause 7.2 alignment |
| Coverage & succession | Single points of failure |
| Vendor personnel controls | When humans are external |
Scenario: High-risk credit model is “owned” by one contractor who alone understands feature pipelines; no backup, no competence file, no knowledge transfer. If the contractor leaves, monitoring and retrain stop. Raise A.4.6 (and continuity/operational planning themes under Clause 8 as applicable).
Sampling Adequacy for High-Risk Systems
Use a structured scorecard per sample system:
| Check | Pass signals | Fail signals |
|---|---|---|
| Inventory completeness | Data, tools, compute, people named | “Unknown vendor model API” in production |
| Currency | Updated after last major retrain | Docs predating current model version |
| Ownership | Named accountable roles | Orphan resources |
| Capacity vs demand | SLOs and retrain cadence supported | Chronic queueing; disabled eval jobs |
| Competence match | Oversight roles trained | Interns approving high-stakes releases |
| Link to risk/impact | Resource limits treated as risks | Known gaps ignored in risk register |
Worked scenario — Logistics demand forecasting
In scope: Weekly demand forecast driving automated purchase orders.
| Control | Finding |
|---|---|
| A.4.2 | Partial runbook; no single resource package |
| A.4.3 | Training data from three ERPs documented; real-time POS stream undocumented |
| A.4.4 | MLflow registry present; production promotion via unmanaged notebook |
| A.4.5 | Inference on shared cluster; no capacity headroom documented for holiday peaks |
| A.4.6 | Data scientist competent; no trained human reviewer for exception queues |
Audit conclusion pattern: Multiple related NCs or one systemic NC on A.4 with examples—plus follow-on risk to operational control and impact if bad forecasts harm suppliers or food safety assumptions.
Common Nonconformities and Traps
- Budget ≠ documentation: Finance approved “AI spend” without system-level resource records.
- Confusing A.4 with A.7: A.4 identifies data resources; A.7 governs quality, provenance, preparation. Cite both when both fail.
- Human resources = headcount only: Missing competence and oversight capacity.
- Cloud shared responsibility ignored: Compute listed as “AWS” with no account, region, or service inventory.
- Low-risk systems over-documented, high-risk systems blank: Inverse risk-based resourcing is itself an AIMS weakness.
Bottom line: A.4 makes AI dependencies visible and manageable. Next, A.5 asks whether the organization assesses who and what society may be harmed when those resourced systems act.
Which grouping correctly reflects the five Annex A.4 controls?
A production medical triage model depends on a third-party LLM API, a hospital EHR extract, GPU inference nodes, a model registry, and on-call clinicians for overrides. Resource documentation lists only “cloud servers.” What should the lead auditor conclude about A.4?
How should A.4.6 human resources be distinguished from A.3.2 roles and responsibilities in audit practice?
When sampling resource adequacy for high-risk AI systems, which approach best fits risk-based auditing?