EU Delays High-Risk AI Rules, U.S. Advances Model Evaluation and Data Center Security, Korea Eases Medical AI Evidence Requirements, China Promotes IPv6 for Large Models

On July 27, 2026, the U.S. National Institute of Standards and Technology (NIST) launched the Artificial Intelligence Technology Evaluation (AITE) program, providing data providers and model providers with voluntary model performance evaluations based on blind data and a sequestered test environment.

AITE is currently in its initial phase and is a voluntary official evaluation program, not legislation, a regulatory rule, or a mandatory technical standard. NIST runs participating models in a sequestered environment without disclosing the test data, reducing the risk of contamination caused by overlap between training and testing datasets. The program offers two participation pathways: data providers submit domain datasets and test tasks that have not been made available to other parties, while model providers submit models for evaluation; NIST supplies common data, metrics, and scoring methods. Initial tasks cover quantum dot control, human genome variant curation, and visual recognition of public-safety events. Results for participating systems and the identities of submitting organisations will be made public, and NIST’s consolidated analysis report will be updated at least annually.

AITE does not directly impose additional compliance obligations on enterprises. Its practical impact lies primarily in the quality of evidence supporting model procurement, admission, and deployment approval. Public leaderboards and supplier-reported scores often cannot establish that test samples were excluded from model training, nor do they necessarily reflect performance on specific business data. In high-error-cost scenarios such as healthcare, scientific research, public safety, and financial risk management, enterprises can draw on the AITE methodology by conducting independent tests with domain data that has not been shared with model suppliers, fixing the model version, prompts, runtime environment, and scoring methods, and retaining the test date, results, error categories, and testing conditions to create reproducible model-evaluation records. Supplier contracts can also specify that customer test data may not be used for training or fine-tuning, and define authorised access, retention periods, and deletion procedures. Continuously updated models should be revalidated after major version changes; scores from an earlier version should not automatically be used to demonstrate that a new version remains suitable for deployment. These arrangements are enterprise-governance recommendations derived from the AITE methodology, not mandatory requirements established by NIST.

AITE is not NIST’s first AI evaluation initiative. The NIST Generative Artificial Intelligence Evaluation Program (NIST GenAI) has primarily evaluated generative models, content-detection models, and prompting strategies across text, image, code, audio, and video modalities. The Assessing Risks and Impacts of AI (ARIA) program examines the risks and impacts of AI systems in specific use contexts through model testing, red teaming, and field testing. AITE’s incremental value does not lie in proposing another set of general risk principles, but in combining a neutral third party, non-public data, common metrics, and a sequestered test environment into a sustainable domain-evaluation mechanism that enables different models to be compared using the same data and metrics.

The same issue is addressed through different institutional pathways in the United States and the European Union. AITE remains public evaluation infrastructure in which enterprises and research institutions participate voluntarily. The EU Artificial Intelligence Act (AI Act), by contrast, imposes legal obligations on high-risk AI systems relating to risk management, technical documentation, automatic logging, and conformity assessment. AITE test results cannot replace the conformity assessment required under EU law, but its blind datasets, common metrics, and test-recording methods may provide useful evidence when enterprises verify expected model performance, compare suppliers, and prepare technical documentation. For enterprises deploying across regions, the United States currently places greater emphasis on building public evaluation methods and testing infrastructure, while the European Union connects model testing more directly to product access, quality management, and legal responsibility.

On July 27, 2026, the U.S. National Institute of Standards and Technology (NIST) published the initial public draft of AI Data Center Security Analysis: A High-Performance Computing-Driven Approach (NIST SP 800-239), conducting a threat and security-gap analysis of AI data centers used for model training, inference, and applications. Public comments are open until September 25, 2026.

The document is currently an initial public draft, not a mandatory standard already in force. Using high-performance computing (HPC) systems as a reference point, the draft divides an AI data center into a compute zone, data storage zone, access zone, and management zone, and identifies differences across hardware, the software stack, workflows, data storage, and external connectivity. The risks covered extend beyond prompt injection and model extraction to include multi-tenant data leakage, hardware, software, and model supply chains, inter-data-center networking, firmware integrity, residual data in GPU memory, and accelerator vulnerabilities. Foundational measures proposed in the draft include AI gateway monitoring, query and response logging, continuous authentication, hardware roots of trust, confidential computing, human approval before models enter production, and fault-tolerant recovery.

For enterprises operating their own compute clusters, renting dedicated GPU cloud capacity, or providing model services to customers, the practical change is that the security boundary cannot stop at the model interface and application layer; it must extend to accelerators, firmware, drivers, high-speed interconnects, storage systems, scheduling platforms, and AI gateways. Enterprises need to be able to answer where training data and model weights are stored, which tenants and administrators have accessed them, how GPU memory and caches are cleared after a task, and who approved a model for production use. Cloud procurement and compute-hosting contracts can accordingly add provisions on tenant isolation, firmware updates, secure boot and device attestation, data deletion, log delivery, and incident notification. Internal operating processes should record model versions, data sources, administrative actions, API requests, and outputs, while monitoring anomalous access and lateral communication across processes. For cross-regional training, enterprises should also preserve records of data location, transmission paths, and administrative access to prevent multi-data-center collaboration from becoming an audit blind spot. These are deployment recommendations based on the draft and do not constitute legal obligations already established by NIST SP 800-239.

The draft continues NIST’s work on high-performance computing security. High-Performance Computing Security: Architecture, Threat Analysis, and Security Posture (NIST SP 800-223), published in 2024, established an HPC reference architecture and threat analysis. High-Performance Computing Security Overlay (NIST SP 800-234), published in May 2026, tailored 60 controls from the NIST SP 800-53B moderate baseline. The current draft further narrows the subject to AI data centers designed specifically for training and inference and states that it will serve as a foundation for subsequent security guidance. Unlike Article 15 of the EU AI Act, which requires high-risk AI systems to maintain an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle, NIST currently follows a voluntary technical-guidance pathway focused on how infrastructure should identify and address risk. Cross-regional enterprises need to map the two categories separately: EU rules determine which systems bear legal obligations, while the NIST draft helps decompose the compute, storage, networking, and operational controls supporting those systems. Compliance with the draft alone cannot replace an EU conformity assessment.

On July 27, 2026, the European Union’s Digital Omnibus on AI—Regulation (EU) 2026/1744 of the European Parliament and of the Council amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence—entered into force, amending the application dates for high-risk AI systems under the Artificial Intelligence Act (AI Act), the interaction with product legislation, and certain compliance procedures. The Regulation was published in the Official Journal of the European Union on July 24, 2026 and, under the rule that it enters into force on the third day following publication, became binding in its entirety and directly applicable in all Member States on July 27.

The amendment first replaces the previous timetable with fixed application dates for the high-risk rules: use-case-based high-risk systems listed in Annex III will be subject to the relevant rules from December 2, 2027, while high-risk systems that are safety components of products listed in Annex I will be subject to them from August 2, 2028. The postponement applies to Sections 1 to 3 of Chapter III, including high-risk classification, risk management, data governance, technical documentation, logging, human oversight, accuracy and cybersecurity, and the obligations of providers and deployers. It does not postpone the AI Act in its entirety. The amendment also clarifies that AI systems performing only user-assistance, performance-optimisation, service-efficiency, or non-safety quality-control functions should, in principle, not be treated as a product “safety component”. Where EU product legislation already provides equivalent or higher protection, the European Commission may use delegated acts to limit certain duplicative obligations. Small and medium-sized enterprises and small mid-cap enterprises may also use simplified forms of technical documentation.

Enterprises should not treat the amendment as a reason to suspend compliance preparations for high-risk AI projects. A more appropriate response is to restructure project timelines. Enterprises should first determine whether a system is a use-case-based system under Annex III, such as one used in recruitment, education, credit, or public services, or a safety component of a product under Annex I, such as a medical device, machine, or aviation product. The two categories have different final application dates, and product-based systems are also subject to conformity assessment under sector-specific legislation. Projects already in procurement or development should continue accumulating documentation on training and test data, model performance records, human-oversight design, and version changes, because the amendment delays the date on which obligations apply but does not remove the requirements themselves. For high-risk systems that depend on foundation models, third-party components, or external data services, supplier agreements should address technical documentation, known limitations, testing interfaces, and compliance assistance in advance, avoiding a situation in which upstream materials cannot be obtained when conformity assessment approaches. These are deployment recommendations based on the final Regulation and do not require every enterprise to complete formal certification immediately.

The EU AI Act entered into force on August 1, 2024. The original timetable would have applied the relevant high-risk obligations for Annex III systems from August 2, 2026 and those for Annex I product-based systems from August 2, 2027. The European Commission subsequently proposed amendments in November 2025, and the Council of the European Union and European Parliament reached political agreement on May 7, 2026. The final Regulation did not adopt an open-ended postponement entirely dependent on the readiness of standards, but instead established new fixed dates. Its recitals attribute the adjustment to delays in harmonised standards, common specifications, and alternative guidance, as well as the incomplete establishment of competent authorities and conformity-assessment infrastructure in the Member States. During the same period, NIST in the United States primarily used the voluntary AITE program to provide blind testing and common evaluation methods. The European Union, by contrast, continues to use directly applicable legislation to define market-access and operational responsibilities, while rescheduling implementation because standards and regulatory infrastructure are not yet fully ready. The difference is that the United States currently focuses more on providing evaluation tools that enterprises may adopt, while the European Union has already fixed the final legal obligations and their application dates.

On July 27, 2026, Korea’s Ministry of Food and Drug Safety (MFDS) issued and implemented Notice No. 2026-54, amending the Regulation on Approval, Certification, Notification, Review and Evaluation of Digital Medical Products (디지털의료제품 허가·인증·신고·심사 및 평가 등에 관한 규정). The amendment adjusts clinical-trial and other evaluation materials for digital medical device software, certification under the Good Management System, and real-world evaluation arrangements.

The amendment does not generally eliminate clinical evidence requirements for medical AI. Instead, it creates exemption or substitution pathways based on software functionality and whether the product claims clinical effectiveness. For functions listed in Annex 3—including treatment, examination, diagnosis, medication assistance, clinical-management guidance, information provision, and information management—that do not claim clinical effectiveness, clinical-trial and other evaluation materials may be waived where specified conditions are met. In particular, products using AI technology for examination, diagnosis, clinical-management guidance, or other purposes may, where they do not claim clinical effectiveness, submit performance-validation results generated using medical and health data as part of software verification and validation materials, replacing certain clinical-trial and other evaluation materials. The amendment also expands eligibility for benefits associated with Good Management System certification from certain Class II standalone software to standalone software with no designated class and Class II standalone software. It further requires post-approval real-world evaluation to be completed within no more than three years after approval or certification, with the report submitted within 30 days after completion of the evaluation.

Enterprises need to redesign the product evidence pathway, not merely remove several filing documents. Product teams should first fix the intended use, output, and clinical claims. For the same medical-imaging analysis function, a system that merely marks an abnormal region without identifying a specific disease may qualify for the performance-validation substitution pathway. A system that outputs a specific diagnosis or claims improved clinical outcomes may still require more complete clinical evaluation. “Not claiming clinical effectiveness” becomes a critical boundary determining the evidence burden, so product descriptions, user interfaces, marketing materials, and hospital-use workflows need to remain consistent. Where medical and health data is used for performance validation, enterprises should document data sources, representativeness of the target population, annotation methods, separation of training and validation datasets, performance metrics, and subgroup differences, ensuring that simplification of the submission format does not weaken reproducibility of the evidence. Enterprises with Good Management System certification also need to place model versions, input and output data, algorithm changes, and real-world evaluation plans under continuous management. Allowing later submission of a real-world evaluation report does not eliminate post-market validation. If the model, intended population, or use environment changes materially, the enterprise must reassess whether the existing evaluation continues to support the product. These arrangements are deployment recommendations based on the final rules and do not mean that all medical AI products are exempt from clinical trials.

The amendment continues Korea’s specialised regulatory pathway following the implementation of the Digital Medical Products Act on January 24, 2025. The initial framework primarily established digital medical device classification, approval review, software quality management, AI change management, and real-world evaluation systems. The July 2026 amendment uses accumulated approval experience to direct different software functions toward full clinical evidence, evidence exemptions, performance-validation substitution, or post-approval real-world evaluation. The regulatory focus therefore shifts from uniform requirements to an evidence package proportionate to functional risk. Compared with the European Union, Korea’s adjustment occurs within specialised digital medical product legislation and focuses on optimising market-entry materials and evaluation timing for medical AI. The EU places qualifying medical-device AI simultaneously under medical-device product legislation and the high-risk framework of the AI Act, adding requirements for risk management, data governance, technical documentation, logging, human oversight, and cybersecurity. Neither pathway reduces medical AI safety assurance to a single model-accuracy test. In Korea, however, enterprises must focus more directly on the question “Which clinical claim requires which evidence?”, while in the EU they must also answer “Is the system high-risk AI, and how do conformity assessments under product legislation and the AI Act interact?”

On July 28, 2026, the Office of the Central Cyberspace Affairs Commission, together with the cyberspace authorities of Beijing, Shanghai, Zhejiang, and Shenzhen and five leading large-model enterprises, launched the “Special Initiative to Enhance IPv6 Capabilities for Large AI Models” in the Xiong’an New Area. The initiative is intended to improve IPv6 support across generative large-model applications, infrastructure, and application programming interfaces (APIs).

This is a one-year administrative promotion and industry-coordination initiative and is currently not legislation, a departmental rule, or a published mandatory technical standard. Publicly announced tasks include improving IPv6 support in large-model infrastructure, increasing IPv6 traffic for large-model applications, raising the share of model API calls accessed over IPv6, improving IPv6 management rules for large models, and promoting integrated innovation between IPv6 and model training, inference, and agent collaboration. The initiative aligns with the Implementation Plan for Deepening Innovation and Integrated Application of Internet Protocol Version 6 (IPv6) Technologies (2026–2030). The Plan requires new consumer-facing generative large-model applications to support IPv6, accelerates upgrades of existing applications, calls for industry large models to support IPv6 when deployed, and proposes studying whether IPv6-related requirements should be incorporated into generative AI service filing procedures. It is important to distinguish that “studying incorporation into filing procedures” remains a future institutional task and should not be described as an IPv6 mandate already added to current filing requirements. Public materials also do not disclose the names of the five participating enterprises, quantitative baselines, acceptance metrics, or the text of any management rules.

For enterprises providing model APIs, online conversational tools, or industry large-model services, the object of transformation is not a single server but the entire network path before and after a user request reaches the model. IPv6 support needs to cover domain name resolution, content delivery networks, load balancing, web application firewalls, API gateways, cloud networks, inference nodes, and monitoring platforms. If any point in the chain can process only IPv4, IPv6 users may be unable to access the service, or requests may fall back to IPv4 midway through the path. Enterprises can begin by creating a service-path inventory, separately testing whether consumer applications, enterprise APIs, management consoles, and callback interfaces can be accessed independently over IPv6, and recording success rates, latency, error rates, and traffic shares for both IPv4 and IPv6. On the security side, access-control lists, rate-limiting rules, intrusion detection, source-address logging, and emergency blocking should also be checked for IPv6 coverage, avoiding a situation in which network connectivity is enabled but gaps remain in log analysis and security policy. IPv6 provides a larger address space and a stronger basis for end-to-end connectivity, but it does not replace user authentication, API authorisation, or key management. Enterprises still need to record network addresses, calling entities, access tokens, and model permissions separately. These are deployment preparations derived from the special initiative and the implementation plan, not uniform legal obligations already imposed on all large-model enterprises.

The initiative continues the development of China’s IPv6 policy from “expanding coverage” toward “integration into specific intelligent applications”. The 2021 action plan primarily promoted IPv6 support for newly launched websites, applications, and mobile internet entry points. The 2026 implementation plan further identifies generative large models, industry models, agent collaboration, computing networks, and model APIs as transformation targets, and calls for cloud products to support IPv6 across all regions, new compute-infrastructure connections to enable IPv6 by default, and security products to be upgraded in parallel. Compared with the initial public draft of NIST’s AI Data Center Security Analysis: A High-Performance Computing-Driven Approach released in the same week, China’s initiative focuses more on network reachability, traffic migration, and infrastructure adaptation, while the U.S. draft focuses on data center threats, architectural differences, and security controls. Both extend the scope of governance below the model-application layer into infrastructure, but enterprises face different implementation questions. In China, the priority is to verify whether services genuinely support end-to-end IPv6. When using the NIST draft as a reference, enterprises must further assess the security boundaries of accelerators, storage, management zones, and multi-tenant environments.