When the Price of AI Becomes a Risk to Your ISMS

More and more companies are embedding generative AI into their security processes: SOC alert triage, log analysis, incident classification, DLP support. Almost always this AI does not run in-house: it comes from a remote provider — Anthropic, OpenAI, and a few others — and is billed per token. This is exactly where a risk that few have put in their risk register hides.

A fact is well known to industry watchers: these prices today are, in all likelihood, artificially low. Providers operate at a loss to capture the market, backed by venture capital. It is penetration pricing. Once the market settles and bargaining power shifts to the supplier, prices will rise: several analysts hypothesize increases of 10x, or more.

For most enterprise uses this is a manageable nuisance: if an activity costs more, you use it less. But there is one case where it is not a nuisance — it is a compliance and continuity risk: when AI is not a productivity tool, but a security control within your ISMS.

The Difference That Changes Everything

A security control, unlike a productivity tool, must be sustainable and effective over time. If tomorrow your automated alert triage, which costs X today, were to cost 10X, only two exits remain, both bad:

1. You switch off the control. You have a security gap and, if that control is in your Statement of Applicability, a non-conformity: a control you can no longer afford is not "monitored and effective", it is a finding.
2. You keep it running at 10X. The cost of your compliance becomes hostage to a third party's pricing power, over which you have no leverage.

The thesis is this: a control whose effectiveness depends on a variable, uncontrollable operating cost set by a supplier with a structural incentive to raise it is fragile regardless of how well it works today. Technical effectiveness is not enough if economic sustainability is in someone else's hands.

Two Risks Not to Confuse

It is worth separating them clearly, because they require different responses:

• Continuity/availability — the provider deprecates the model, changes its policies, leaves the European market. Known ground: already covered by business continuity and supply chain security.
• Repricing (cost-shock) — the cost rises suddenly and significantly. This is the novel part, and the least guarded.

The common mistake is to treat the second as the first. A supplier can be perfectly available, reliable, and compliant, and still multiply the price. Continuity of service does not protect against continuity of cost.

What the Frameworks Already Say

The tools to name this risk already exist. DORA is the most direct ally: it names concentration risk on third-party ICT providers and mandates exit strategies and lock-in management (Articles 28–30). AI inference is, in effect, a third-party ICT service, and cost concentration — depending for a critical function on a price you do not control — is a natural variant of it.

ISO/IEC 27001:2022: the supplier and cloud controls (A.5.19–5.23) and ICT readiness for business continuity (A.5.30) frame the relationship. But the strongest hook is a principle of the standard: controls must be monitored for their effectiveness. A control you might have to switch off for budget reasons must be honestly reflected in risk treatment and in the Statement of Applicability.

NIS2 (Article 21.2, supply chain security) completes the picture on the supplier front.

Not All Tasks Are Equal

Model substitutability is not uniform. For many security tasks, small open-weight models — runnable in-house at a predictable cost — do much of the work: there the economic lock-in is weak and self-hosting is a real way out. Where you genuinely need a frontier model, the lock-in is strong, and it is strong exactly where it matters most. The operational question is not "does AI expose me to cost-shock?", but: which of my AI-based controls are load-bearing on a capability I cannot substitute?

What to Do

The risk is not eliminated, it is governed:

1. Map the dependency. For every control that uses AI, record in the risk register its criticality, the model's substitutability, and the cost per unit of work.
2. Decouple from the supplier. An abstraction layer between your processes and the providers turns substitution into a configuration change, not a project.
3. Plan for graceful degradation. Every critical control should have a fallback (typically a local model): a cost-shock must mean reduced quality, not a control switched off.
4. Treat cost as a continuity KPI, not just a budget line, with alert thresholds in the ISMS.
5. Use contractual levers where they exist: price-locks and change notice periods are negotiated before, not after, the shock.

In Short

Adopting AI in security processes is the right choice. But it means also outsourcing the future price of one of your own security measures, to a supplier with every incentive to raise it. And if an entire sector rests on the same two or three providers, cost-shock becomes a systemic risk — the very concern DORA expresses about the cloud. Maturity is not avoiding AI: it is putting it in the risk register before the market reminds you.