EU AI Act in practice: what deployers should have in place in 2026

A practical governance framework for companies integrating third-party AI into products, internal workflows and customer-facing services.

AI / Regulation · 2026

Executive summary. This Lexbridge note focuses on the operational decisions behind the legal issue: what teams should identify, which controls deserve priority and what evidence should exist when the decision is later reviewed.

Start with use cases, not labels

The first practical task is to identify where AI is actually used: customer-facing features, employee tools, decision support, fraud detection, content generation, ranking, analytics and embedded third-party functionality. A single product may contain several distinct use cases with different roles and risk profiles. Governance becomes much easier once those uses are visible and owned.

Know your role in the value chain

A business may be a deployer for one system, a provider for another and a distributor or importer in a different context. Contracting and compliance obligations follow those roles. Product, procurement and legal teams should therefore maintain a simple role map rather than relying on a generic statement that the company “uses AI”.

Build the evidence trail early

Policies alone will not demonstrate compliance. Organisations should retain model and vendor information, use-case approvals, evaluations, human-oversight design, incident records, training materials and material changes. The best evidence is generated by normal product and procurement workflows rather than reconstructed later.

Connect vendor contracts to governance

Third-party model agreements should support the organisation’s own obligations. Documentation access, change notices, security commitments, data-use restrictions, regulatory cooperation and exit rights should be reviewed against the actual use case rather than treated as generic procurement points.

Plan for change

Models, prompts, datasets and vendor terms can change faster than traditional software dependencies. Governance should therefore define when a change is material enough to trigger re-review, who receives provider notices and how product teams document the decision to continue, restrict or replace a system.

Questions for the operating team

  • Who owns the decision and who needs to approve an exception?
  • What evidence should be retained through the normal workflow?
  • Which customer, vendor or regulatory commitments depend on this issue?
  • What change would trigger a new review?
  • What is the practical fallback if the preferred position cannot be achieved?

Lexbridge perspective

The strongest legal position is one that the business can actually operate. That means linking the rule to ownership, systems, contracts and evidence rather than treating legal advice as a document that sits outside the workflow. For cross-border matters, the same operating model should make clear where local advice is needed and which team remains accountable for the overall decision.

Good legal design reduces the distance between the rule and the person who must act on it.