A technical and market analysis of regulatory change, cryptographic resilience, AI infrastructure, and the emerging economics of trustworthy artificial intelligence.

Research cut-off: 4 November 2026

Artificial intelligence is no longer evolving solely as a software engineering discipline. It is becoming critical infrastructure: embedded in financial services, healthcare, public administration, industrial automation, identity verification, cybersecurity, and national security. As its deployment expands, the question confronting the technology industry is no longer simply how capable an AI system can become, but how its reliability, integrity, confidentiality, and security can be demonstrated throughout its operational lifecycle.

The European Union's Artificial Intelligence Act (Regulation (EU) 2024/1689) represents an important shift in this direction. It introduces a risk-based regulatory framework that changes the responsibilities of organisations developing, distributing, and deploying artificial intelligence. Its influence extends beyond model development and governance. It intersects with cybersecurity architecture, cryptographic assurance, software supply-chain security, data protection, and the economics of technology procurement.

However, one distinction is essential: the EU AI Act does not prescribe encryption algorithms or establish a new cryptographic standard. Its significance for cryptography is indirect but strategically important. By establishing requirements for cybersecurity, robustness, confidentiality, and resilience in specified AI systems, it changes what organisations must demonstrate about the security of their technologies.

This distinction matters because the next phase of AI security will not be determined by regulation alone. It will emerge from the interaction between regulatory compliance, advances in cryptography, increasingly sophisticated attacks against AI systems, and the commercial demand for infrastructure that can be trusted.

The central argument of this analysis is that the EU AI Act is helping move AI security from a discretionary engineering consideration towards a demonstrable operational and commercial requirement. The implications will become more visible as the 2027 and 2028 implementation milestones approach.

1. The regulatory shift: What has actually changed?

The EU AI Act entered into force on 1 August 2024. Its provisions have been introduced progressively rather than becoming applicable simultaneously.

This phased approach is important because the law has already influenced the governance of AI models, while its principal requirements for high-risk AI systems are scheduled to become applicable in 2027 and 2028.

The regulatory position as of November 2026 is as follows:

An important development occurred in 2026.

Regulation (EU) 2026/1744, commonly referred to as the Digital Omnibus on AI, amended the implementation framework. Among other changes, it established the December 2027 and August 2028 application dates for the principal requirements concerning Annex III and Annex I high-risk systems.

The delay was associated with the availability of standards, guidance, common specifications and the institutional arrangements needed to support implementation.

This should not be interpreted as a suspension of the entire AI Act. Several obligations are already applicable, including rules concerning prohibited practices, AI literacy, general-purpose AI models and transparency.

The distinction between the applicable rules and future implementation milestones is fundamental to understanding the actual regulatory impact.

Primary legal references: Regulation (EU) 2024/1689 — consolidated text and Regulation (EU) 2026/1744 — Digital Omnibus on AI.

2. Artificial intelligence and cryptography

To understand the impact on cryptography, it is necessary to examine how modern AI systems are constructed.

A production AI system is rarely just a model. It involves training datasets, preprocessing pipelines, model repositories, inference infrastructure, APIs, identity systems, monitoring services, external integrations and sometimes autonomous agents capable of interacting with other software.

Every component introduces a security dependency.

A compromised dataset can influence model behaviour. An unauthorised modification to a model can change its outputs. Exposed credentials can provide access to sensitive inference infrastructure. Poorly controlled retrieval systems can disclose information that was never intended to be accessible to a particular user.

Consequently, securing an AI system requires protecting the integrity and confidentiality of the entire technology lifecycle.

This is where cryptography becomes relevant.

Cryptographic mechanisms provide some of the foundational properties upon which secure AI infrastructure can be built:

• Confidentiality: Protecting sensitive data, model parameters and communications from unauthorised access.
• Integrity: Establishing whether datasets, model artifacts and software components have been modified.
• Authentication: Verifying the identities of users, systems, services and infrastructure components.
• Non-repudiation and provenance: Supporting verifiable records of actions, approvals, releases and data origins.

These properties are not interchangeable, and encryption alone cannot solve every AI security problem.

For example, encrypting a training dataset protects it while stored or transmitted, but does not automatically prevent a model from disclosing information learned from that dataset. Similarly, encrypting model weights does not establish that the model was trained on trustworthy data.

The emerging engineering requirement is therefore not merely stronger encryption. It is a coordinated security architecture combining cryptographic controls, privacy engineering, system monitoring, access governance and adversarial evaluation.

2.1 Article 15: A significant connection to cryptographic security

Article 15 is particularly important for understanding the relationship between the AI Act and cybersecurity.

It requires high-risk AI systems to achieve appropriate levels of accuracy, robustness and cybersecurity throughout their lifecycle.

More importantly, Article 15(5) directly addresses attempts by unauthorised third parties to alter the use, outputs or performance of AI systems by exploiting vulnerabilities.

Its technical considerations include protection against:

• Data poisoning.
• Model poisoning.
• Adversarial examples and model evasion.
• Confidentiality attacks.
• Model vulnerabilities and unauthorised interference.

These are not theoretical concerns confined to academic machine learning research. They represent practical security challenges for deployed AI infrastructure.

Consider an AI-assisted financial assessment system. An attacker may attempt to influence its training data, manipulate inputs, access sensitive information or compromise the model's deployment environment.

The security problem is not limited to protecting the database. It includes the integrity of the learning process, the model's operating environment, its access permissions and the reliability of its outputs.

A security architecture that combines authenticated data pipelines, signed model artifacts, controlled deployment permissions, secure key management and continuous adversarial evaluation becomes considerably more meaningful under this regulatory approach.

It is important to recognise that Article 15 does not mandate any particular cryptographic implementation. The organisation must select technical and organisational safeguards appropriate to the system and its risks.

Official interpretation: European Commission AI Act Service Desk — Article 15.

3. Five cryptographic developments gaining strategic relevance

The AI Act does not independently create these technologies or require their universal adoption. Nevertheless, its security objectives, alongside wider privacy and cybersecurity regulations, make several cryptographic capabilities increasingly relevant to AI infrastructure.

3.1 Privacy-preserving machine learning

One of the most important developments is the use of privacy-enhancing technologies in machine learning.

Traditional AI development frequently involves transferring datasets into centralised training environments. This creates challenges when datasets contain personal, financial, medical or commercially sensitive information.

Privacy-preserving approaches aim to reduce unnecessary exposure while allowing useful computation.

Several technologies deserve attention.

Differential privacy introduces mathematically characterised privacy guarantees by limiting how much the inclusion of an individual record can influence a computation. It is particularly relevant when publishing model outputs, statistics or information derived from sensitive datasets.

Federated learning allows multiple participants to train a shared model without necessarily centralising their original datasets. However, federated learning alone does not guarantee privacy. Model updates can still leak information, making secure aggregation and other protections important.

Homomorphic encryption enables certain computations to be performed on encrypted data without first decrypting it. Its potential applications include sensitive-data processing and selected machine learning workflows, although computational overhead remains a significant practical constraint.

Secure multiparty computation enables multiple participants to jointly calculate results without each participant having to reveal its private inputs to the others.

The commercial opportunity is substantial in sectors where organisations need to collaborate on intelligence without transferring unrestricted access to their underlying datasets.

Healthcare research, financial fraud detection, public-sector analytics and cross-institutional scientific research are particularly relevant examples.

The important market question is no longer whether privacy-preserving computation is theoretically possible, but where its security benefits justify its computational and operational costs.

3.2 Cryptographic provenance and model integrity

The origin and integrity of AI models are becoming increasingly important.

Modern AI applications rely on pretrained models, external datasets, open-source dependencies and third-party infrastructure. This creates a supply-chain problem: how can an organisation establish that the model it deployed is the same model it evaluated and approved?

Cryptographic signing provides one answer.

A model artifact can be associated with a digital signature. Its hash can be recorded during release, and its integrity can be verified before deployment. Similar mechanisms can protect dataset versions, container images, configuration files and software updates.

This creates the possibility of verifiable model-release pipelines.

A more advanced implementation could connect:

1. Dataset provenance and version history.
2. Training and evaluation records.
3. Model artifact signatures.
4. Deployment approvals.
5. Runtime configuration and access events.

Such an architecture provides a stronger foundation for technical audits and incident investigations.

Tamper-evident logging can also help establish whether records have been modified. Hash chains, digital signatures and protected log storage can support this requirement.

Blockchain, however, is not inherently necessary. A conventional signed and access-controlled audit system may be more efficient and appropriate.

3.3 Hardware-backed security and trusted execution environments

As AI workloads move into distributed cloud infrastructure, confidential computing becomes increasingly relevant.

Trusted execution environments (TEEs) seek to protect code and data during execution within defined hardware security boundaries.

Technologies based on hardware-backed isolation can reduce exposure to privileged infrastructure components, depending on their implementation and threat model.

This creates possibilities for processing sensitive AI workloads in environments where the infrastructure operator should not have unrestricted access to the data being processed.

The combination of encryption, hardware-backed isolation, workload attestation and controlled key release can strengthen the security of AI services.

However, TEEs are not a universal solution. Hardware vulnerabilities, side-channel attacks, attestation weaknesses and implementation errors remain relevant considerations.

The practical opportunity lies in combining confidential computing with appropriate identity, cryptographic and operational controls.

3.4 Digital signatures, identity and machine accountability

The increasing adoption of AI agents introduces a security issue that traditional application architectures were not designed to handle at scale.

An AI agent may invoke APIs, access files, interact with external applications or delegate tasks to other services.

In such environments, organisations need to establish which human user, service identity or automated process initiated an action.

Cryptographic identity and authentication can support this requirement.

Potential applications include signed machine identities, short-lived credentials, workload authentication, API request signing, authenticated model deployment and verifiable approval workflows.

The underlying principle is straightforward: an automated system should not receive unrestricted authority merely because it operates within an authenticated application.

The identity and permissions of each participating component should be independently verifiable.

This becomes especially relevant as human oversight, traceability and cybersecurity move closer together in enterprise AI governance.

3.5 Post-quantum cryptography: A parallel transition with major consequences

Post-quantum cryptography (PQC) deserves separate treatment.

It is sometimes incorrectly presented as a direct requirement of the EU AI Act. It is not.

The transition to quantum-resistant cryptographic algorithms is being driven by a wider combination of cryptographic research, national security priorities, standards development and regulatory initiatives.

The concern is that sufficiently capable quantum computers could threaten widely deployed public-key cryptographic systems.

The security implications extend to encrypted information that may be collected today and decrypted in the future, commonly described as the harvest-now-decrypt-later problem.

In August 2024, the National Institute of Standards and Technology (NIST) published three major post-quantum cryptographic standards:

In October 2026, NIST also published its final IR 8547 report on transitioning from quantum-vulnerable cryptography to post-quantum standards.

Meanwhile, the European Commission issued a coordinated implementation roadmap in June 2025 to support the transition across EU Member States.

The EU's Cyber Resilience Act introduces another relevant dimension. Its vulnerability-handling and product-security requirements make long-term security maintenance and updateability commercially important. Its main application date is 11 December 2027, although certain provisions apply earlier.

These developments should be understood together, but not conflated.

The AI Act does not require all AI systems to migrate to ML-KEM or ML-DSA. The broader PQC transition creates a separate demand for cryptographic inventory, algorithm replacement, interoperability testing and long-term product maintainability.

For vendors building AI infrastructure expected to operate for many years, cryptographic agility is increasingly a strategic design consideration.

References: NIST post-quantum standards, NIST IR 8547, and the European Commission's PQC roadmap.

4. AI security is evolving beyond conventional cybersecurity

One of the most consequential implications of modern AI regulation is the need to distinguish between using AI to secure infrastructure and securing the AI infrastructure itself.

These are two different markets with overlapping technologies.

Traditional cybersecurity focuses on assets such as endpoints, networks, applications, identities, databases and cloud infrastructure.

AI security introduces additional attack surfaces:

• Prompt injection and instruction manipulation.
• Model extraction and unauthorised model access.
• Training-data poisoning.
• Retrieval-system information leakage.
• Adversarial input manipulation.
• Insecure agent tools and permissions.
• Model and dataset supply-chain compromise.
• Confidentiality attacks against model behaviour.

These threats cannot be resolved exclusively through conventional network security.

An enterprise may have a properly configured firewall, encrypted database and authenticated API while its AI application remains vulnerable to malicious instructions embedded in retrieved content.

Likewise, a model can operate within a secure cloud environment and still expose sensitive information through its responses.

This is why AI security requires its own technical evaluation discipline.

The EU AI Act's provisions concerning high-risk systems and systemic-risk general-purpose models provide an important regulatory basis for this development.

Under Article 55, providers of general-purpose AI models classified as having systemic risk must conduct model evaluations, document adversarial testing, assess and mitigate systemic risks, report relevant serious incidents and ensure adequate cybersecurity protection for both the model and its physical infrastructure.

These obligations are particularly important because they are not simply a future 2027–2028 issue. The applicable GPAI provisions began applying on 2 August 2025.

The implication is that security assurance must increasingly extend beyond the application layer to the model, its dependencies and the infrastructure supporting it.

Reference: AI Act Service Desk — Article 55.

5. The 2027–2028 period: Why the next two years matter

The next two years are likely to be particularly consequential for organisations operating in regulated AI markets.

They represent a transition from an initial period of governance development towards the application of the Act's principal high-risk system requirements.

The distinction between the two major categories is important.

2 December 2027: Annex III high-risk systems

This covers specified AI applications in areas including employment, education, access to essential services, critical infrastructure, biometrics, law enforcement and other sensitive domains.

Providers and deployers will need to address the applicable requirements covering risk management, data governance, technical documentation, record-keeping, human oversight, accuracy, robustness and cybersecurity.

For cybersecurity vendors, this creates opportunities in system evaluation, auditability, continuous monitoring and access governance.

For cryptographic engineering teams, the practical focus will be on demonstrable integrity, confidentiality, identity management and protected operational records.

2 August 2028: Annex I product-related high-risk systems

This milestone concerns AI systems that fall within the relevant product-safety framework.

Examples may include qualifying AI components used in medical devices, machinery and other regulated products.

The implications are different from those of ordinary enterprise AI applications because these products may already operate within established conformity-assessment and product-safety environments.

AI security will therefore increasingly intersect with embedded systems, industrial control environments, hardware assurance, software updates and long-term product maintenance.

The 2028 milestone also coincides with the AI Act's scheduled evaluation and reporting cycle under Article 112.

Importantly, organisations should not assume that every existing AI product automatically receives a universal extension until these deadlines. The Act contains transitional provisions, including conditions concerning significant design changes and special provisions for systems intended for public authorities.

The commercial consequences will depend on the actual classification of each system and its applicable transition rules.

6. Market valuation: Where is the money moving?

Regulation creates economic incentives, but it does not automatically create a market of equivalent size to the entire AI industry.

An important analytical distinction is necessary.

The market for AI used in cybersecurity is different from the market for security products designed to protect AI systems.

The first includes technologies using artificial intelligence to detect threats, automate security operations and improve defensive capabilities.

The second includes products protecting models, training pipelines, inference systems, agents and AI-related data.

Market research often combines or categorises these segments differently. Treating every published AI cybersecurity valuation as the size of the AI security market would therefore be misleading.

Nevertheless, available forecasts provide useful indicators of investment direction.

Selected market indicators

Sources: Gartner's AI spending research, MarketsandMarkets PQC research, and Gartner's September 2026 forecast.

These figures should not be combined into one total addressable market. They describe different technology categories, and the market-research methodologies are not necessarily comparable.

More importantly, there is no single consistently defined, independently measured valuation for the entire market of securing AI systems.

That market is distributed across existing cybersecurity, identity, privacy, cloud infrastructure, model evaluation and governance categories.

The opportunity should therefore be evaluated at the product and customer-problem level rather than through an artificially constructed mega-market estimate.

6.1 The commercial opportunities emerging from this transition

Several segments deserve particular attention.

AI security evaluation and adversarial testing

Organisations will increasingly need ways to evaluate model behaviour under realistic attack conditions.

This creates demand for red-teaming platforms, prompt-injection testing, model vulnerability assessments, safety evaluations and continuous security testing.

The strongest commercial products will connect identified vulnerabilities to measurable remediation and operational risk reduction.

Secure AI infrastructure and MLOps

The demand for model integrity, authenticated deployment pipelines and controlled model access creates opportunities for software that integrates security into the AI development lifecycle.

Potential products include model registries with signed artifacts, secure dataset ingestion, deployment attestation and AI-specific software supply-chain monitoring.

Privacy-enhancing technologies

Healthcare, finance and public-sector organisations represent potential customers for technologies enabling protected data collaboration.

The opportunity extends beyond encryption products to complete privacy-preserving computation services.

AI governance and compliance infrastructure

Many organisations lack a consolidated view of their AI systems, their intended purposes, data sources, dependencies, risks and associated documentation.

Products that automate inventory management, risk classification, technical documentation, evidence collection and post-deployment monitoring could become valuable enterprise infrastructure.

However, a generic compliance dashboard is unlikely to be sufficiently defensible. Products need to integrate with actual engineering and operational workflows.

Post-quantum migration

The move towards post-quantum cryptography creates opportunities in cryptographic discovery, dependency analysis, migration planning, hybrid implementations, certificate management and long-term security maintenance.

The strongest businesses may provide solutions that operate across existing enterprise infrastructure rather than requiring customers to replace their entire technology stack.

7. Investment implications: What makes an AI security company valuable?

The regulatory environment creates opportunities, but regulatory alignment alone should not be confused with commercial viability.

A company claiming to be AI Act compliant does not necessarily possess a defensible technical product.

Investors and enterprise buyers should examine five factors.

First, the product must solve a demonstrable security problem. A platform that detects model tampering, identifies excessive agent permissions or validates model artifacts has a more tangible value proposition than a product that merely generates compliance documentation.

Second, it must integrate with existing infrastructure. Security tools that require enterprises to rebuild their development environments face significant adoption barriers.

Third, it must generate measurable outcomes. Detection accuracy, false-positive rates, reduced incident exposure, evaluation coverage and engineering time saved are more useful indicators than the number of compliance reports generated.

Fourth, the business must possess a credible technical advantage. This could come from proprietary evaluation datasets, specialist cryptographic implementation, strong integrations, specialised research or operational expertise.

Finally, the company must understand the economics of enterprise procurement. Security products often face lengthy sales cycles, extensive vendor reviews and demanding integration requirements.

The more attractive opportunity is therefore not simply to build another AI compliance platform. It is to develop infrastructure that makes AI systems demonstrably safer, more observable and easier to operate securely.

8. The global impact: From European regulation to international technology policy

The EU AI Act has implications beyond the European market because technology companies rarely operate within single regulatory jurisdictions.

Its territorial scope can cover organisations outside the EU when their systems are placed on the EU market, used within the Union or produce outputs used within the Union under the conditions established by Article 2.

This creates a potential international spillover effect.

The mechanism is relatively straightforward.

A technology company serving European customers may decide that maintaining separate product architectures for different regulatory markets is economically inefficient.

It may consequently develop a common security and documentation baseline that also influences products sold elsewhere.

This is one reason the AI Act is often discussed in connection with the so-called Brussels Effect: the ability of European regulatory standards to influence international business practices.

However, global harmonisation should not be assumed. Different jurisdictions continue to have different approaches to data protection, national security, competition, AI governance and market access.

United States

The United States has pursued a different regulatory approach, combining federal initiatives, technical standards and sector-specific requirements.

NIST plays a significant role through its AI Risk Management Framework and post-quantum cryptography standards.

The commercial environment is also important. US technology companies developing cloud services, AI models and security infrastructure may need to meet European requirements when serving EU markets.

Consequently, interoperability between technical standards and regulatory frameworks is likely to become increasingly valuable.

China

China's AI governance environment is shaped by its cybersecurity, data-security and personal-information protection frameworks, alongside regulations concerning generative AI and algorithmic services.

Its approach reflects different national priorities concerning data governance, public security and technological sovereignty.

European requirements may influence the export architecture of Chinese AI services, but the regulatory models should not be treated as equivalent.

India: An important strategic opportunity

India occupies an especially interesting position.

It has a large technology services industry, a growing AI startup ecosystem, expanding digital infrastructure and increasing participation in international software supply chains.

India also has its own evolving governance framework.

The India AI Governance Guidelines, released by MeitY on 5 November 2025, establish a principle-based approach focused on responsible, inclusive and trustworthy AI development.

They emphasise safety, accountability, fairness, transparency and innovation.

The guidelines should be distinguished from directly applicable statutory obligations. India's Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 provide a separate legal framework for personal-data processing and security safeguards, with phased commencement.

Furthermore, the IndiaAI Mission, approved with an outlay of ₹10,371.92 crore, supports the development of India's AI compute infrastructure, foundation models, datasets, startups and safe and trusted AI capabilities.

These developments create a strategic opportunity.

Indian technology companies can position themselves not merely as AI development vendors but as providers of secure AI engineering, regulatory interoperability and cryptographic infrastructure.

For example, an Indian enterprise software provider supplying AI-powered recruitment technology to European customers may need to understand the relevant high-risk classification, documentation obligations, cybersecurity requirements and deployment responsibilities.

An organisation building medical AI infrastructure for international markets may similarly need to integrate product safety, cybersecurity and AI governance into one engineering process.

The opportunity is to make these capabilities part of the product architecture rather than treating them as an administrative exercise performed immediately before market entry.

India's competitive advantage will depend not only on access to computing resources or its engineering workforce, but also on its ability to develop trustworthy, secure and globally interoperable technology.

Relevant sources: India AI Governance Guidelines — PIB, MeitY — DPDP Rules 2025, and IndiaAI Mission.

9. What developers, researchers and technology founders should do now

The most useful response to the evolving regulatory environment is not to wait until the legal deadlines arrive.

Engineering decisions made today can either reduce or amplify future security and compliance costs.

For software developers, the first priority should be understanding the complete AI supply chain. Identify the models being used, the sources of training and retrieval data, external dependencies, service identities, API permissions and deployment environments.

Security testing should then extend beyond conventional penetration testing. AI-specific evaluations should examine prompt injection, data extraction, adversarial behaviour, model integrity and misuse of external tools.

Cryptographic controls should be introduced where they provide measurable protection. This includes authenticated communication, protected secret management, signed model artifacts, secure update mechanisms and appropriately protected audit records.

For research teams, promising areas include privacy-preserving machine learning, cryptographic provenance, confidential computing, adversarial robustness, secure federated learning and post-quantum migration.

For founders, the opportunity is to build focused products around measurable customer problems. There is a considerable difference between selling a generic compliance checklist and providing an infrastructure component that prevents a real security failure.

A practical implementation roadmap can be divided into three periods.

2026: Establish visibility and technical foundations.

Inventory AI systems, classify their purposes, map dependencies, establish threat models and evaluate the adequacy of data protection, authentication, logging and model integrity controls.

2027: Operationalise assurance.

Prepare the relevant technical documentation, integrate security evaluation into development pipelines, establish incident-response procedures and address the requirements applicable to Annex III systems and legacy GPAI models.

2028: Extend assurance into product infrastructure.

For relevant Annex I systems, integrate AI governance with established product safety and conformity processes. Review model updates, cryptographic dependencies, lifecycle security and post-market monitoring.

This roadmap should be adapted to each organisation's actual legal classification and applicable transition provisions.

10. The limitations and risks of regulation-led innovation

A serious analysis must also consider the limitations of the regulatory approach.

Regulation can improve minimum security expectations, but it cannot guarantee that an AI system will be secure.

A formally documented risk-management process does not automatically prevent a successful attack. Encryption cannot eliminate model inference vulnerabilities. A cryptographically signed model can still contain harmful behaviour. A conformity assessment cannot replace continuous monitoring.

There is also a cost dimension.

Large enterprises can afford dedicated compliance, security and legal teams. Smaller technology companies may face proportionally higher implementation costs.

If standards and technical guidance remain fragmented, businesses may struggle to understand which controls are appropriate or how to demonstrate conformity.

Another concern is regulatory over-compliance: organisations may invest heavily in documentation and certification exercises without proportionately improving their underlying security architecture.

This creates a risk that compliance becomes a substitute for engineering rather than a framework that strengthens it.

There is also the possibility of market consolidation. Vendors with existing legal, technical and infrastructure capabilities may find it easier to meet enterprise procurement requirements than smaller independent developers.

The policy objective should therefore be to establish meaningful security outcomes without making high-quality AI development economically inaccessible to smaller innovators.

Conclusion: The next competitive advantage will be verifiable trust

The EU AI Act is not a cryptography regulation, and its impact should not be exaggerated by presenting every development in encryption, privacy engineering or quantum-resistant security as a direct consequence of European AI legislation.

Its importance is more fundamental.

It contributes to a changing technology environment in which AI systems must increasingly demonstrate that they are governed, secure, resilient and appropriately monitored.

The Act's cybersecurity requirements, particularly Articles 15 and 55, establish a connection between AI governance and practical security engineering. The 2027 and 2028 milestones will extend this pressure across additional categories of high-risk systems, while parallel legislation and cryptographic standardisation initiatives continue to influence infrastructure decisions.

For cryptography, the opportunity lies in protecting the integrity, authenticity and confidentiality of increasingly complex AI pipelines.

For cybersecurity, it lies in developing methods capable of identifying and mitigating vulnerabilities that traditional security products were not designed to address.

For the market, it lies in turning security assurance into useful, interoperable products rather than treating regulation as an administrative burden.

For countries such as India, it lies in developing AI infrastructure that can compete internationally not only on cost and capability, but also on security, accountability and trust.

The central market transition is therefore not from unregulated AI to regulated AI. It is from AI systems whose security is largely assumed to AI systems whose security must increasingly be evidenced.

That transition will create challenges for developers, raise the bar for enterprise infrastructure and open opportunities for companies working at the intersection of artificial intelligence, cryptography and cybersecurity.

The next generation of successful AI infrastructure will not be defined by computational capability alone. It will be defined by the ability to establish, preserve and independently demonstrate trust.

References and further reading

Legislation and regulatory sources

1. Regulation (EU) 2024/1689 — European Union Artificial Intelligence Act
2. Regulation (EU) 2026/1744 — Digital Omnibus on AI
3. European Commission AI Act Service Desk — Article 15
4. European Commission AI Act Service Desk — Article 55
5. Regulation (EU) 2024/2847 — Cyber Resilience Act

Cryptography and cybersecurity research

1. NIST — Post-Quantum Cryptography Standards
2. NIST IR 8547 — Transition to Post-Quantum Cryptography Standards, October 2026
3. European Commission — Coordinated PQC Implementation Roadmap, June 2025
4. European Commission — Recommendation on the Transition to Post-Quantum Cryptography, April 2024

Market and national policy research

1. Gartner — Worldwide AI Spending Forecast, May 2026
2. MarketsandMarkets — Post-Quantum Cryptography Market Research
3. MeitY — India AI Governance Guidelines
4. MeitY — Digital Personal Data Protection Rules, 2025
5. Government of India — IndiaAI Mission

Editorial note: Market figures are third-party forecasts, not audited market revenues. Regulatory dates reflect the legislation consolidated through 27 July 2026. The article distinguishes binding statutory requirements, implementation milestones, technical standards and market projections. It is an analytical technology article, not legal advice.