An AI BOM governance checklist for documenting AI system components, data, suppliers, controls and ownership with evidence you can defend.
Topics: AI Governance, EU AI Act, AI Registry, Risk Management, Compliance
An AI system can move from a contained pilot to a business-critical service before anyone has a complete record of what it contains, who operates it, or where its decisions affect people. An AI BOM governance checklist gives governance teams a controlled way to document those dependencies and assign ownership before gaps become embedded in day-to-day operations.
An AI bill of materials, or AI BOM, is more than an inventory of models. It is the operational record of the components, data, suppliers, integrations, controls and accountable people that make an AI system function. For organisations managing EU AI Act obligations alongside GDPR, UK GDPR and other privacy requirements, this record creates the connection between technical activity and demonstrable governance.
Why an AI BOM needs governance
A static spreadsheet can identify an AI tool, but it rarely shows whether its information remains current, whether a risk decision was approved, or whether a change triggered reassessment. That distinction matters. AI systems change through model updates, new data sources, altered prompts, supplier releases and expanded use cases. Governance must therefore manage the AI BOM as a living record, not a one-off exercise.
The level of detail should reflect risk. A low-impact internal productivity tool does not require the same depth of evidence as an AI system influencing recruitment, credit decisions, access to services or other high-impact outcomes. However, every system needs a named owner, a defined purpose, a clear supplier position and a route for escalating material changes.
A useful AI BOM also prevents duplicated effort. Privacy, legal, security, procurement, risk and technology teams can work from the same controlled record rather than maintaining separate lists that disagree on the system's purpose, data flows or approval status.
AI BOM governance checklist
Use the following checklist to establish a repeatable control process. The objective is not to produce more documentation. It is to maintain the evidence and accountability needed to operate AI systems responsibly at scale.
1. Establish the system identity and business purpose
Start with an unambiguous system record. Capture the system name, business owner, technical owner, operating entity, intended users and jurisdictions where it is deployed. Describe the business purpose in plain language, including the decision, recommendation, prediction or content-generation activity involved.
This is where scope failures often begin. A system initially approved to assist support agents may later be used to generate customer-facing responses. That is not merely a configuration change. It may alter the affected population, data use, human oversight requirements and risk classification. The AI BOM should distinguish approved use from actual use and identify prohibited uses where appropriate.
2. Record models, components and integrations
Document the model or models used, including provider, version, hosting arrangement and whether the model is proprietary, open source, fine-tuned or embedded in a wider product. Record the key components around it: orchestration tools, vector databases, application interfaces, monitoring services and connected business systems.
This layer is essential for supplier governance and change management. A supplier's model release, a new plug-in or an added integration can affect security, privacy, performance and legal responsibilities even if the business-facing application appears unchanged. Where component-level detail is supplied by a third party, retain the supplier evidence and record any limits on visibility.
3. Map data inputs, outputs and processing activities
The AI BOM should identify what data enters the system, where it comes from, how long it is retained, who can access it and what outputs are produced. Separate personal data, special category data, confidential business information and publicly available data. Do not assume that a vendor's general statement about training practices answers these questions for a particular deployment.
Link the record to the organisation's ROPA where personal data is processed. If the use is likely to create a high risk to individuals, connect it to the relevant DPIA and capture the resulting mitigation actions. A Legitimate Interest Assessment may also be required where legitimate interests form the legal basis. These connections turn an AI inventory into an operational compliance record rather than an isolated technology register.
4. Classify risk and define the assessment route
Apply a documented method to determine the system's risk profile. For organisations in scope of the EU AI Act, this includes determining whether the intended use falls within a prohibited practice, high-risk category, transparency obligation or another applicable classification. The classification should be supported by evidence, assumptions and an accountable approval decision.
Risk classification is not permanent. A new user group, data source, automated action or deployment country can change the analysis. Set a review trigger for those changes rather than relying only on an annual review. The right approach depends on the system's impact and rate of change: high-impact systems may need formal review before each material release, while stable lower-risk tools may be reviewed on a scheduled basis.
5. Assign accountable owners and control responsibilities
Every AI BOM entry needs named accountability. The business owner should remain responsible for intended use and operational outcomes. A technical owner should manage system configuration, changes and performance. Privacy, legal, security and risk stakeholders should have defined review responsibilities, not vague advisory roles.
Specify who approves deployment, who can accept residual risk, who monitors controls and who must be notified of an incident. Where a third party operates the model or application, clarify the organisation's responsibilities against the supplier's responsibilities. Contract review and DPA redlining should reflect the actual data flows, security commitments, audit rights, subcontractor position and incident obligations recorded in the AI BOM.
6. Document human oversight and operational controls
Human oversight should be specific to the system's risk. Record whether people review outputs before action, can override recommendations, receive training, or are given limits on when the system may be used. For systems that influence people materially, document escalation paths, decision challenge processes and safeguards against over-reliance on automated outputs.
The record should also capture controls for access management, testing, logging, output quality monitoring, data minimisation and restricted use. A control that exists only in a policy is difficult to evidence. Link each material control to an owner, implementation status and supporting artefact such as a test result, procedure or approval record.
7. Assess suppliers and downstream dependencies
Supplier risk assessment should extend beyond the primary AI vendor. An AI service may rely on cloud infrastructure, annotation providers, sub-processors, external data sources or model marketplaces. The governance question is not whether every dependency can be audited directly. It is whether the organisation understands which dependencies are material and has proportionate assurance for each.
Capture supplier due diligence, contractual commitments, locations of processing, continuity arrangements and the supplier's change-notification process. For a higher-risk deployment, evidence of model documentation, security controls, testing practices and incident support may be necessary. If evidence is unavailable, record that limitation and the decision made to manage it.
8. Build change, incident and evidence workflows
An AI BOM becomes reliable when it is integrated with operational workflows. Material changes should create a review task, notify the right owners and, where needed, trigger updates to the DPIA, ROPA, supplier assessment or AI risk classification. Breach and incident management processes should identify whether an event involves an AI system, affected data, problematic outputs, model misuse or supplier failure.
Maintain a clear evidence trail: assessment decisions, review dates, approvals, supplier documents, test records, training evidence, incidents and remediation actions. Privacy360 supports this model by bringing the AI system registry and EU AI Act risk classification into the same operational environment as DPIAs, ROPA, vendor assessments, contract review and incident management. The benefit is control continuity across teams, rather than a collection of disconnected artefacts.
Make the checklist a managed lifecycle
The checklist is most effective when it is embedded into procurement, development, deployment and change processes. Require an AI BOM record before a new system is approved. Make completion of defined assessment tasks a condition of production release. Then use periodic review and event-driven triggers to keep records current.
Avoid treating completeness as the only measure of success. A register with every system listed but no assigned owner, evidence or review workflow is still a governance gap. Better indicators include the proportion of systems with current risk classification, completed supplier assessment, linked privacy assessment, tested controls and closed remediation actions.
The practical test is simple: when a senior stakeholder asks how an AI system works, what data it uses, who approved it and what happens when it changes, the organisation should be able to answer from one controlled record. That is the standard an AI BOM should help establish.