How an AI BOM review turns AI governance policy into operational control, with system profiles, review triggers, evidence owners and EU AI Act readiness.
Topics: AI Governance, EU AI Act, AI BOM, Risk, Privacy Operations
AI BOM Review for Controlled AI Governance
An AI BOM review is where an AI governance programme becomes operational. A policy may state that high-risk systems require oversight, but a governance team cannot assess, classify or evidence control of a system it cannot describe accurately. The AI bill of materials, or AI BOM, provides that description: a structured record of the models, data, suppliers, software components and human decisions that make an AI system work.
For organisations deploying AI across multiple business functions, the challenge is rarely a lack of intent. It is fragmented information. Legal may know the contractual position, security may understand the technical environment, procurement may hold supplier records, and the business owner may be testing new functionality without a complete view of its downstream dependencies. An effective review brings those records into one accountable process.
What an AI BOM review should establish
An AI BOM is not simply an inventory of AI tools. A basic inventory may tell an organisation that it uses a generative AI assistant or a fraud-scoring model. It does not show which model version is in use, where inputs are processed, whether personal data is involved, which external provider supports the service, or what happens when the model output informs a significant decision.
The review should establish a reliable system profile that can be used by privacy, legal, risk, security and the accountable business team. At minimum, that profile needs to connect the AI system to its purpose, owner, intended users, deployment context and decision impact. It should also identify the foundation model or models, embedded components, training and retrieval data sources, interfaces, hosting arrangements, suppliers, and material human oversight points.
That level of detail is proportionate to the system. A narrowly scoped internal drafting assistant does not require the same review depth as an AI system supporting recruitment, credit decisions, customer eligibility or other sensitive operational outcomes. The principle is consistent: governance effort should reflect the system's risk, dependency chain and potential impact on individuals or the organisation.
The review must distinguish the AI system from the supplier
A recurring control gap arises when a supplier assessment is treated as the entire AI assessment. Supplier due diligence is necessary, but it does not answer how the organisation has configured, deployed and supervised the AI system in its own environment.
The same external model can create very different risk profiles depending on the data entered into it, the prompts and guardrails applied, the user population, the integration with internal systems and whether outputs are advisory or determinative. An AI BOM review should therefore link supplier evidence to the organisation's actual use case. This creates a clearer basis for contract review, DPA redlining, vendor and third-party risk assessment, and internal accountability.
Why AI BOM reviews matter for EU AI Act readiness
The EU AI Act places greater emphasis on disciplined AI system oversight, including risk classification and documented controls. An organisation does not need to wait for a formal classification exercise to begin building the underlying evidence. In practice, classification is only as reliable as the information available about the system.
A complete AI BOM helps teams identify whether the use case could fall within a prohibited practice, a high-risk category, a transparency-related obligation or a lower-risk deployment that still requires controlled use. It also highlights questions that cannot be answered from a procurement record alone: whether the system processes special category data, supports a regulated decision, affects vulnerable groups, or uses biometric, behavioural or profiling information.
This work should sit alongside, rather than separate from, existing privacy governance. Where personal data is processed, the AI BOM should inform the Data Protection Impact Assessment tool and, where relevant, a Legitimate Interest Assessment. It should also connect to the organisation's ROPA record so that processing activities, data flows, retention arrangements and processor relationships remain consistent across the programme.
The value is operational. A privacy lead should not need to reconstruct the same facts from emails, supplier questionnaires and technical documents whenever a regulator, auditor or internal committee asks how an AI system works.
Review the system at entry, change and exception points
A one-off AI BOM review will quickly become outdated. AI systems change through model upgrades, new integrations, altered data sources, expanded user groups and revised supplier terms. Some changes are minor. Others can materially alter risk without changing the name of the product used by the business.
A workable control model sets clear review triggers. These typically include a new AI system, a new use case for an existing system, a change of model or provider, a connection to a new data source, an expansion into a new jurisdiction, and a shift from human review to automated action. A security incident, complaint, unexpected output pattern or supplier notification may also require the record to be revisited.
The aim is not to create approval friction for every configuration change. It is to make material change visible and route it to the appropriate owner. Lower-risk changes may only require the AI system registry to be updated. Higher-impact changes may require privacy assessment, legal review, security validation, procurement engagement and a fresh risk classification.
Assign evidence to named owners
An AI BOM is valuable only if its entries can be verified. Broad statements such as "the supplier is compliant" or "human oversight applies" are difficult to defend because they do not identify evidence, scope or responsibility.
Each critical record should have a named owner and a source of evidence. For example, the business owner can confirm the intended purpose and users; IT or security can validate technical architecture and access controls; procurement can maintain commercial and supplier records; legal and privacy can assess lawful basis, contractual terms and individual impact. The governance function coordinates the record, challenges gaps and maintains the decision trail.
This ownership model matters most when teams are lean. Rather than relying on a central privacy team to chase every detail, the organisation creates a repeatable workflow in which each function contributes the information it already controls. Escalations become more focused because reviewers can see what is known, what is assumed and what remains unresolved.
What weak reviews miss
The most common weakness is recording only the front-end application. An organisation may log an AI-enabled customer service platform while omitting the external model provider, the retrieval database, call transcripts, prompt logs, analytics tools and downstream case-management integration. That leaves the organisation unable to trace personal data, supplier exposure or failure points.
Another weakness is treating model documentation as static. A supplier's published materials may be useful, but they are not a substitute for understanding the deployed version, contractual commitments, regional processing arrangement and organisation-specific controls. Where a provider changes a model or service feature, the impact depends on how the organisation is using it.
Finally, some reviews capture risk but not the action taken. A defensible record should show the decision, any conditions of deployment, the control owner, the review date and the rationale for accepting or reducing the risk. Without this, risk assessment becomes a document rather than a managed control.
Build the review into one governance system
The strongest operating model connects the AI BOM to the workflows that already govern data and third parties. An entry in the AI system registry should not sit alone. It should be capable of referencing the DPIA, ROPA, supplier assessment, contract and DPA review, risk classification, incident record and remediation actions associated with that system.
This connection reduces duplicate data entry and exposes inconsistencies early. If an AI system is marked as using no personal data but its connected processing record identifies customer transcripts, the discrepancy can be investigated before it becomes an audit issue. If a supplier assessment expires, the teams responsible for AI oversight can see which systems may require follow-up.
Privacy360 supports this operating model by bringing AI system oversight, EU AI Act risk classification, privacy assessments, ROPA, contract review, vendor assessments and incident management into one structured environment. The objective is not more documentation. It is a controlled record that reflects how the organisation actually deploys AI and assigns accountability for keeping that record current. Teams that want specialist support standing up AI governance and EU AI Act readiness can also engage Formiti's consulting services.
A useful AI BOM review should leave decision-makers with more than a list of technology. It should show what the system does, what it depends on, whose data and rights may be affected, who owns each control, and what must happen when the system changes. That is the foundation for AI governance that can withstand growth, scrutiny and operational reality.