Many companies may be tempted to treat AI risk management like they have other regulatory requirements: GDPR compliance, DSA/DMA fines... Those frameworks are relatively straightforward to pin down.
The GDPR gives you specific definitions for categories of data breaches, distinguishing serious non-compliance from less serious infractions based on mitigation or intent. The fines are tied to clear thresholds.
The EU AI Act, by contrast, only defines prohibited practices and high-risk AI systems. There’s a common misconception that it also accurately defines what counts as limited-risk, low-risk, or medium-risk. It doesn’t.
Which means that even if you successfully avoid use cases classified as prohibited or high-risk, you haven’t necessarily avoided enforcement exposure.
Scope creep is a real problem. Misclassifying your role as a downstream provider, distributor, or importer can mean that when a complaint happens, you’re hit with a fine you weren’t expecting, because you thought you knew what your role was.
Repurposing technologies for different use cases is another minefield. Similarly to how the GDPR restricts using personal data for purposes different from those for which it was collected, the AI Act introduces categorisations where repurposing an architecture for a different use case can trigger compliance obligations you didn’t anticipate.
But if we focus only on the EU AI Act, and if we focus only on fines, we’re making a huge (and expensive) mistake.
Most tech companies don’t develop foundation / general purpose AI1 models. But they’re deploying them, or building products on top of LLMs, or automating workflows using AI agents.
If this is your case, you’re still exposed to frontier risk.
Here’s what I mean:
You might be using OpenAI’s API, Anthropic’s Claude, or an open-weight model from Hugging Face. You might have security middleware in place: guardrails, content filters, prompt injection defences. You might have convinced yourself that you’ve contained the risk at the application layer.
But misalignment is misalignment.
It lives in the foundation model’s internals, and it finds its way out. It will interact with your security layers at the middleware level and at the application level in ways you didn’t predict. Because, even if you only use models via orchestration services with added security, you still don’t control the model’s learned representations or its trained decision-making process.
You don’t control what internal representations the foundation model (GPT-4, Gemini 2.5 Flash, Claude Sonnet 4.5…) learned to encode during training.
You didn’t train it, you can’t audit its weights, and you can’t reliably predict how it will generalise to novel inputs.
What you do control are the layers you build around it: your own middleware security, your application architecture, your monitoring systems, your product design decisions.
This is why Responsible AI is the only meaningful safeguard available when you’re building on systems whose internals remain fundamentally opaque.
And why equating Responsible AI to ‘compliance’ is like putting fire extinguishers in the same category as the paperwork you fill out after the fire happened.
There’s an entire field (AI Safety) trying to figure out how to reliably get advanced, agentic AI to do what we want it to do, according to human expectations and values. And they’re struggling.
Interpretability research tells us that, due to how these models learn through high-dimensional pattern recognition and emergent feature formation, we can’t accurately reverse-engineer their internal reasoning or predict how learned concepts will generalise to novel contexts. We don’t have reliable access to why a model produces a given output, only correlations between activations and observed behaviour.
Scalable oversight asks: how can we supervise agents that are faster, more capable, and operating in domains beyond human expertise? If the system can outpace your ability to evaluate its outputs, how do you maintain meaningful control?
AI Control asks: if it’s really this difficult to align AI, how can we still use it safely without losing control over it? What techniques can we deploy to reduce catastrophic risk even when misaligment is present?
These aren’t abstract research questions. They’re the operating conditions you’re building under when you deploy LLMs or agents in production.
This isn’t narrow AI. Narrow AI (your recommendation engine, your fraud detection model) has bounded, deterministic behaviour within a defined task space.
We know how to test it. We know how to audit it. We know what failure looks like.
Frontier AI is different.
Foundation models exhibit emergent abilities (capabilities that appear unpredictably at scale2) which propagate to the AI agents built on top of them.
They generalise in ways their developers didn’t explicitly “program”. Leading scholars like Chris Olah have said that frontier models are not programmed or built, but discovered: because the parts you do code (training algorithms, architecture) prepare the system to learn in ways you don’t code and cannot predict or fully understand.
And yet, most companies now want to “leverage” exactly this sort of AI. The business case is compelling: natural language interfaces, automated reasoning, context-aware decision-making. But the risk profile is fundamentally different from anything you’ve deployed before.
Traditional regulatory risk (GDPR, DSA, DMA) follows a familiar formula:
Expected cost = probability × impact × detectability × mitigation.
You can quantify each variable based on precedent, breach fines, enforcement patterns, turnover thresholds.
Frontier AI risk breaks that equation.
Probability is indeterminate. You can’t assign meaningful likelihood to emergent behaviours that have no prior or causal anchor. The model might behave one way in testing and another way in deployment because the input distribution shifted in ways that activated different learned features.
Impact is nonlinear. Small changes (prompt context, fine-tuning data, user interaction patterns) can produce qualitatively different failures. A model that performs well on your benchmarks might still hallucinate credentials, leak training data, or produce outputs that expose you to various legal risks.
Mitigation is probabilistic. Interpretability tools, evaluation frameworks, and monitoring provide partial coverage. You’re managing risk, not eliminating it.
You’re not dealing with “expected” risk. You’re dealing with latent systemic risk, with a predictability closer to climate or financial contagion modelling than to data protection breaches.
GDPR compliance is a transaction cost. You document processes, train staff, respond to Supervisory Authorities. It’s expensive, but it’s bounded.
AI governance is a control cost, and it scales superlinearly with model complexity.
Why? Because your governance doesn’t just document what’s happening: it has to constrain something that evolves after deployment.
Model drift, adversarial inputs, fine-tuned misuse, novel jailbreaks. When using Frontier models, the gap between what your AI system can do and what your governance knows it does is itself a financial liability, even before enforcement.
The true cost of General Purpose AI risk includes:
Continuous validation infrastructure. Sandboxing, red-teaming, adversarial testing, ensuring enough explainability. You need to know when your system starts behaving differently, and you need to catch it before your users do.
System behaviour audits. Internal and third-party. You can’t audit what you can’t observe, and right now, most companies can’t observe models’ internal decision-making as these are downstream with black box access only.
Post-deployment monitoring pipelines. Logging, anomaly detection, drift analysis.
Contractual and insurance gaps. There’s no standardised underwriting for frontier model externalities yet. Your insurance probably doesn’t cover emergent AI risk. Your vendor contracts probably don’t allocate liability for model failures in any meaningful way, and how these liabilities are allocated when the vendor itself builds their solution on frontier models, will be a fun challenge for the courts in the coming years.
Compliance verifications happen ex post, after the fact. Responsible AI is something you build ex ante.
It’s risk assurance. Like we said before, even the insurance sector is struggling to define metrics for insuring AI actors and their systems.
When you use foundation models you don’t control, whose developers can’t tell you exactly how they’ll behave in different scenarios, Responsible AI might be the only safeguard you actually have.
Not because of compliance. Not because of fines. But because it’s the only way to semi-reliably stay on top of emerging risks from technologies that you do not have real control over.
You don’t have this problem, at this scale of unpredictability, with normal software.
Reducing Responsible AI to compliance, or pretending that emergent risk in general-purpose AI can be calculated and offset like traditional cyber risk instead of embedding responsible practices from the beginning, is dangerous. And it’s just wrong.
Responsible AI isn’t a regulatory “nice to have”. You want to quantify it?
Well, it’s the price of partial predictability in a non-deterministic environment.
Without that investment, you’re not just exposed to regulatory fines. You’re exposed to systemic loss of control.
Kathryn Conrad & Rose Willis / https://betterimagesofai.org / https://creativecommons.org/licenses/by/4.0/
We will use Frontier and General Purpose AI (GPAI) interchangeably in this post. But, for clarity’s sake:
(1) The European Artificial Intelligence Act defines it as “AI model, including where such an AI model is trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications”. And, in Art 51: “A general-purpose AI model shall be presumed to have high impact capabilities pursuant to paragraph 1, point (a), when the cumulative amount of computation used for its training measured in floating point operations is greater than 10(^25).”
(2) California’s SB 53 does a better job at defining “frontier model”, as “a foundation model that was trained using a quantity of computing power greater than 10^26 integer or floating-point operations.”
“An ability is emergent if it is not present in smaller models but is present in larger models. Emergent abilities would not have been directly predicted by extrapolating a scaling law from small-scale models. When visualized via a scaling curve, emergent abilities show a clear pattern—performance is near-random until a certain critical threshold of scale is reached, after which performance increases to substantially above random.” – Jason Wei et al., “Emergent Abilities of Large Language Models”
No posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.