What should development and security teams do first to reduce quantum and AI risk together?

Development and security teams should begin with practical readiness work: map where cryptography is used, pilot post-quantum controls, and expand AI security governance at the same time. The article also recommends using AI security frameworks such as NIST AI RMF and MITRE ATLAS, while building the monitoring and detection capability needed to spot risky AI usage early.

Where to start when quantum and AI risk overlap

Teams should start by inventorying the places where cryptography and AI governance actually touch live systems, rather than treating quantum readiness and AI security as separate programmes. That means identifying certificates, key management dependencies, authentication flows, model pipelines, and decision points where AI is already influencing development or operations. The first useful outcome is a shared map of exposure, because without it, planning tends to overinvest in abstract roadmaps and underinvest in the systems that will fail first.

For the quantum side, that map should highlight where current cryptographic choices create long-term migration pressure. For the AI side, it should show where models, prompts, agents, and automated workflows introduce governance or abuse risk. The practical goal is to prioritise the systems that carry both technical dependency and business consequence. The NIST AI Risk Management Framework is useful here because it helps teams structure AI risk work without assuming that every AI issue is the same, and it complements cryptographic readiness rather than replacing it.

In practice, many security teams encounter the real quantum and AI exposure only after legacy cryptography, shadow AI use, and ad hoc model adoption are already embedded in production delivery.

How to turn readiness into a practical programme

The most effective first move is to build one cross-functional readiness view that development, security, platform, and architecture teams can all use. That view should not just record assets; it should describe where change will be hard, where trust is concentrated, and where controls are missing. On the quantum side, that usually means classifying cryptographic dependencies by where they sit in the stack, how difficult they would be to replace, and whether they protect data that must remain confidential for a long time. On the AI side, it means identifying which systems generate, transform, recommend, or act on data, and where human approval is still required.

A short working sequence is usually more useful than a large programme plan:

Inventory cryptographic use cases, with attention to externally exposed services and long-life data.
Inventory AI use cases, including embedded tooling, agents, and third-party model services.
Rank systems by business criticality, confidentiality horizon, and governance complexity.
Pilot controls where the dependencies are easiest to observe and measure.
Use the pilot to define policy, logging, and ownership patterns before broad rollout.

That sequencing matters because quantum readiness is partly a migration problem, while AI security is partly an operating model problem. The two can share inventory, monitoring, and governance work, but they do not share the same remediation path. For AI-specific threat behaviour, the NIST AI Risk Management Framework and the NIST Cyber AI Profile are useful because they help teams connect governance with operational controls rather than treating AI as a policy-only issue.

This guidance breaks down when organisations try to solve both risks with one tool purchase, because the underlying work is still inventory, prioritisation, and control ownership.

Where the combined plan gets complicated

Tighter readiness planning often increases coordination overhead, requiring organisations to balance faster visibility against the extra effort of maintaining inventories, ownership, and review gates.

One common edge case is that quantum risk often has a long time horizon, while AI risk can be immediate and operational. That difference changes prioritisation. If a system uses weakly governed AI today, it is a current exposure; if it depends on cryptography that will need migration later, it is a future resilience issue unless the data has a long confidentiality requirement. Teams should not collapse those timelines into one score without separating the consequence of compromise from the difficulty of migration.

Another subtle point is that not every AI-enabled workflow needs the same level of control. Guidance versus consensus matters here: there is broad agreement that high-impact or externally exposed AI needs stronger governance, but there is less consensus on how much assurance is sufficient for low-risk internal use. Teams should therefore avoid forcing a single standard across all use cases and instead define thresholds for review, logging, and human override. The operational mistake is to treat “AI risk” as a single category or to treat “quantum readiness” as purely a cryptography team problem.

Where the programme becomes weakest is in shared responsibility gaps. If developers assume security will define the inventory, and security assumes platform engineering will maintain it, neither readiness track will be trustworthy enough to guide action.

Risk and Threat Considerations

The combined risk is not just technical debt. It is exposure created by unknown cryptographic dependencies, uncontrolled AI usage, and weak governance over systems that may already influence business decisions or data handling. The most material risk is that organisations will believe they are “preparing” while their highest-value systems remain poorly mapped, poorly monitored, or difficult to change.

Failure mechanism: Risk materialises when organisations cannot see where cryptography is embedded, where AI is being introduced, or which workflows depend on trust assumptions that are not documented. That creates a failure chain in which migration effort is underestimated, risky AI use spreads faster than controls, and critical systems remain outside the pilot scope until remediation becomes expensive.

Impact: The result can be delayed cryptographic transition, weaker governance over model use, reduced confidence in automated decisions, and greater exposure if a sensitive system must be changed under time pressure. In a worst case, both readiness tracks become reactive instead of preventative, which makes recovery slower and assurance harder to prove.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATLAS address the attack surface, NIST AI RMF, NIST AI 600-1, NIST CSF 2.0, CIS Controls v8 and NIST IR 8596 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST AI RMF	GOV-1 — Govern	AI governance and accountability are central to the question.
Recommendation — Establish AI governance ownership before scaling model or agent use.
NIST AI 600-1	MAP-1 — Measure and Map AI Risks	Teams must map AI exposure and prioritise likely failure points.
Recommendation — Map AI use cases and associated risks before expanding deployment.
MITRE ATLAS	ATLAS-TA0001 — Reconnaissance	The question explicitly concerns spotting risky AI usage early and abuse patterns.
Recommendation — Use ATLAS to hunt for observable AI abuse and adversarial behaviour.
NIST CSF 2.0	ID.AM-1 — Asset Management	Inventorying cryptographic and AI dependencies is the first practical step.
Recommendation — Inventory cryptographic and AI-dependent assets before planning controls.
CIS Controls v8	Control 1 — Inventory and Control of Enterprise Assets	Readiness begins with knowing which systems and dependencies exist.
Recommendation — Maintain an accurate inventory of systems, dependencies, and owners.

Practitioner Guidance

What to prioritise: Build a single inventory of high-value systems that shows both cryptographic dependency and AI usage, then rank those systems by business criticality and change difficulty. That gives teams one practical queue instead of competing programmes.

What to verify: Confirm who owns each system, where the control boundary sits, and whether the team can actually observe key events such as model invocation, credential use, or crypto dependency changes. If ownership or logging is unclear, the readiness plan is not yet operational.

Decision rule: Treat systems with long-lived confidential data, external exposure, or autonomous AI actions as the first wave for review. Those are the places where both quantum migration pressure and AI governance risk are most likely to become material.

Practitioner takeaway: The best first step is not choosing between quantum and AI programmes, but building one trusted view of where both risks already live in production so the first controls land on the systems that matter most.