AI compliance fails when it remains a policy document owned by legal, while product, procurement, security and operations make the decisions that shape real-world risk. Knowing how to operationalise AI compliance means turning regulatory obligations and internal principles into repeatable controls that teams can use before an AI system is bought, built, changed or retired.
For organisations operating across borders, this is not a single EU AI Act workstream. AI governance intersects with GDPR and UK GDPR accountability, data protection impact assessments, information security, supplier management, sector-specific requirements and local rules in the markets where systems are deployed. The practical question for leadership is not whether governance exists. It is whether the organisation can demonstrate who approved a use case, what data it uses, how its risk was assessed and whether the agreed controls are operating.
Start with an AI operating model, not a policy
An AI policy sets expectations. An operating model assigns decisions, evidence and accountability. Both are necessary, but they solve different problems.
Begin by defining an accountable executive sponsor and an AI governance forum with authority to approve, restrict or stop high-risk uses. This group should bring together legal, privacy, information security, risk, procurement, data and the business owners of AI-enabled products. It should have a defined remit, meeting cadence, escalation route and record of decisions.
The operating model also needs clear ownership at system level. Every AI system should have a named business owner who is accountable for the purpose, intended users, data sources, supplier relationship, controls and ongoing review. Without this ownership, an inventory soon becomes a static register and significant changes can pass through ordinary delivery processes without assessment.
For larger organisations, a three-team delivery model is particularly effective. Legal interprets applicable obligations and contractual requirements. Privacy translates data protection duties into use-case controls, including impact assessments and transparency requirements. Technical operations implements the workflows, access controls, documentation and monitoring that make those decisions sustainable. This prevents AI governance from becoming either legal theory or an isolated technical exercise.
Build an AI system inventory that supports decisions
You cannot govern AI systems that cannot be identified. A useful AI inventory goes beyond a list of chat tools and machine-learning models. It records systems developed internally, configured through third parties, embedded in enterprise software, used by staff, or supplied to customers.
For each entry, capture enough information to support triage and oversight: the system’s business purpose, owner, jurisdictions, affected groups, deployment status, model or provider, input and output data, level of human involvement, integrations, vendors, and whether personal data or special category data is processed. Record intended use as well as actual use. A tool acquired for document summarisation may later be used to rank candidates, recommend credit actions or support clinical decisions, which changes the control requirements materially.
The inventory should connect to existing records rather than create another disconnected spreadsheet. Link it to records of processing activities, DPIAs, vendor assessments, contracts, information asset registers, security reviews and incident records where relevant. A platform such as Privacy360 can provide a controlled workflow and central evidence trail, but the essential point is governance design: the register must be maintained by business processes, not an annual data-gathering exercise.
Classify risk before selecting controls
Risk classification should be proportionate to the use case. Treating every AI tool as high risk wastes specialist capacity and encourages teams to bypass the process. Treating low-visibility systems as low risk because they are supplied by a familiar vendor creates the opposite problem.
A structured intake should first establish whether the intended use may be prohibited, restricted or subject to specific obligations under applicable AI rules. It should then assess data protection impact, the significance of decisions or recommendations, the people affected, potential discrimination or accuracy concerns, reliance on automated outputs, security exposure and the organisation’s ability to oversee the system.
Risk classification is not a one-time label. It should be revisited when there is a material change, such as a new data source, model update, expansion into another country, new decision-making purpose, or change in supplier terms. This is particularly important for generative AI services, where model capabilities, retention arrangements and enterprise controls can change frequently.
Match the assessment to the use case
Not every system requires the same depth of review. A low-impact internal drafting assistant may need an approved-use assessment, data-handling rules, vendor assurance and user guidance. An AI system that helps make decisions about individuals will normally require a more detailed assessment covering lawful processing, human oversight, explainability, testing, security, record-keeping and escalation.
The assessment must produce an operational outcome. It should state whether the system is approved, approved with conditions, paused pending remediation, or not permitted for the proposed purpose. Conditions should be assigned to named owners and tracked to completion. Vague findings such as “monitor bias” are not controls. A defined testing method, review frequency, threshold for intervention and owner are controls.
Embed compliance in procurement and delivery gates
Most organisations do not need a separate bureaucracy for every AI initiative. They need AI controls embedded at the points where decisions already occur.
In procurement, add AI-specific questions to supplier due diligence and contract review. Establish what the supplier provides, whether customer inputs are used to train models, where data is processed, how access is controlled, what documentation is available, how model changes are communicated, and how incidents or performance concerns are managed. Contractual commitments should reflect the assessed role of the supplier and the data involved, rather than relying on generic terms.
In product and change delivery, introduce gates at ideation, design, pre-release and material change. The first gate identifies the use case and routes it for triage. The design gate confirms data, risk and control requirements. Pre-release checks that conditions are complete, training is delivered and evidence is retained. The change gate ensures that updates do not silently invalidate the original assessment.
The right level of control depends on delivery speed and risk appetite. A central approval board for every minor experiment can delay useful innovation. A tiered model is usually more effective: self-service guidance for approved low-risk uses, targeted review for moderate-risk cases, and formal multidisciplinary approval for higher-impact deployments.
Make human oversight real and measurable
Human oversight is often described too broadly to be useful. A person clicking “approve” after an automated recommendation is not meaningful oversight if they lack the information, authority or time to challenge it.
Define what the human reviewer sees, when they intervene, what decisions they can overturn and how they record reasons. Provide role-specific training for staff who use AI outputs in customer, employee, financial, healthcare or other consequential contexts. They need to understand the system’s limits, common failure modes, prohibited uses and escalation path.
Monitoring should be tied to the risks identified at assessment. Depending on the system, this may include quality checks, output sampling, false positive or false negative trends, complaints, override rates, access logs, security events and supplier performance. Set review triggers in advance. A sudden rise in overrides, for example, should lead to investigation rather than merely appearing in a quarterly dashboard.
Treat supplier assurance as continuous governance
Third-party AI does not transfer accountability. Suppliers can provide valuable technical documentation and assurances, but the deploying organisation remains responsible for deciding whether a system is suitable for its purpose and environment.
Create a supplier assurance process that is proportionate to criticality. High-impact systems may require detailed documentation, testing evidence, audit rights, incident notification provisions, change-management commitments and periodic reviews. For lower-risk tools, a standard assessment and clear acceptable-use rules may be sufficient.
Cross-border deployments need additional discipline. Data flows, local representation requirements, language obligations, sector rules and AI governance expectations can differ by market. An organisation expanding into Europe, the UK, Switzerland or Asia should assess whether the same use case can operate under a common global baseline or needs local controls. A common framework is efficient; pretending every jurisdiction is identical is not.
Preserve evidence for leadership and regulators
Operational AI compliance is evidenced through records, not assurances. Maintain a clear trail of inventories, classifications, impact assessments, approvals, testing, training, supplier reviews, incidents, changes and periodic reassessments. This evidence enables board reporting, internal assurance and a controlled response when customers, auditors or regulators ask questions.
Board reporting should focus on decisions and exposure: which high-impact systems are live, which approvals are conditional, where remediation is overdue, what supplier dependencies exist and whether governance performance is improving. It should not overwhelm directors with technical detail that does not support oversight.
For organisations without extensive internal capacity, managed support can provide the continuity needed to operate these controls across multiple jurisdictions. Formiti combines legal, privacy and technical operations expertise across more than 120 countries and 100 regulatory frameworks, helping teams establish governance that works within existing business processes.
The first practical step is simple: select the AI use cases already creating the greatest business value or potential exposure, assign an owner, and run them through the operating model. A well-governed pilot produces the evidence, templates and decision discipline needed to scale with confidence.