Emerging Technologies & AI.

In almost all cases, yes, if you develop, deploy or distribute an AI system that touches the EU market. The AI Act sorts systems into four tiers — unacceptable risk (banned outright, such as certain manipulative or social-scoring practices), high risk (subject to conformity assessment, technical documentation, human oversight and registration requirements), limited risk (transparency obligations, such as disclosing that content is AI-generated) and minimal risk (largely unregulated). The classification depends on what the system does and who it affects, not on what industry you're in, and it is rarely as obvious as it first appears. We assess the system against the Act's criteria and document the classification to a standard that holds up under scrutiny.

No, and this is one of the most consequential misconceptions we see. The absence of AI-specific legislation for your exact use case does not mean the absence of legal exposure. Product liability law, consumer protection law, general tort principles and sector-specific safety regulation all continue to apply to AI, robotics and autonomous systems regardless of whether bespoke AI rules exist yet. Courts and regulators are already applying existing frameworks to novel technology, and being first to market with something genuinely new does not delay the point at which liability can attach. We assess exposure by reasoning from the legal principles that do apply, rather than waiting for a rule that names your product specifically.

The two frameworks apply simultaneously and independently — satisfying one does not satisfy the other. A high-risk AI system that processes personal data needs both an AI Act conformity assessment and a GDPR-compliant lawful basis, and in many cases a Data Protection Impact Assessment covering the AI-specific risks the system introduces (profiling, automated decision-making, novel inference from data). The two regimes also use different vocabulary for overlapping concepts, which is where compliance programmes that treat them as separate workstreams tend to develop gaps. We handle both together under a single methodology, so the overlap is addressed once rather than twice.

Product liability and safety come first — who is responsible when a robot or autonomous system causes harm, and what evidence will demonstrate the system was designed and tested responsibly. Type-approval and sector-specific safety regimes may apply depending on the product category, often well ahead of any AI- or AV-specific legislation catching up. Data governance matters too, since these systems typically collect sensor and environmental data at scale. And cross-border questions arise quickly — a vehicle or robot that operates or is sold across jurisdictions inherits a different liability and regulatory picture in each one. We work through these systematically before launch, not after an incident forces the question.

A policy document is a starting point, not a governance programme. A functioning programme includes defined oversight roles, a documented risk classification for each system in use, technical documentation that is actually maintained as systems change, and a review cadence that catches new deployments before they go live unassessed. Regulators and claimants test what an organisation can actually produce and demonstrate, not what a policy states in principle. Building the governance programme before it is tested — rather than after a regulator or an incident forces the question — is materially cheaper and more defensible.