Research date: 7 October 2026. This document reviews the original six instruments and expands them into a global reference for AI gateway, local inference, and connected application controls. Sources are legislation, regulators, government agencies, standards publishers, and the organisations that publish the security frameworks.
The distinction between a published obligation and its application to OneVir is explicit:
- Binding law: enforceable where the jurisdiction, activity, actor, and commencement conditions apply.
- Supervisory expectation: regulator guidance for a specified regulated sector, such as OSFI E-23.
- Standard or voluntary guidance: an assurance or risk-management reference; it does not become a worldwide statutory duty merely because OneVir uses AI.
- OneVir application: an engineering interpretation of a cited requirement or recommendation. Sources do not prescribe OneVir configuration names, numerical thresholds, or architecture.
This is a requirements reference, not a code audit or a finding that OneVir already implements these controls. Coverage includes major relevant regimes in Europe, North America, Asia, Latin America, Africa, the Middle East, and Australia; it is not an inventory of every country's laws or every US state law.
1. Review of the original six instruments
The six are useful references, but they have different legal status and scope. They are not six interchangeable certifications or six universal gateway requirements.
| Instrument | Verified status and scope | Meaning for OneVir |
|---|---|---|
| ISO/IEC 27001:2022 | Requirements for an organisation's information security management system, including risk assessment and treatment. ISO describes protection of confidentiality, integrity, and availability. It is an international standard, not an AI-specific statute. ISO publication. | Support the operator's security controls and evidence. A gateway feature list alone does not establish conformity of an organisation's management system. |
| ISO/IEC 42001:2023 | Requirements for establishing, implementing, maintaining, and continually improving an AI management system. Applies to organisations providing or using AI-based products or services. ISO publication. | Support governance, accountable operation, and improvement. Replace the original description of deployment “benchmarks” with its actual management-system scope. |
| NIST AI RMF 1.0; NIST AI 600-1 | The AI RMF is voluntary and uses Govern, Map, Measure, Manage. The July 2024 Generative AI Profile addresses generative-AI risks including confabulation, harmful bias, privacy, information security, and value-chain integration. NIST AI RMF, final Generative AI Profile. | Use for documented risk assessment, evaluations, monitoring, and treatment. Do not describe it as an enforceable US AI law or a product certification. |
| EU AI Act, Regulation (EU) 2024/1689, as amended | Binding, with distinct prohibited-use, high-risk-system, transparency, and general-purpose AI model obligations. The Commission confirms the AI Omnibus entered into force on 27 July 2026; Annex III high-risk duties apply from 2 December 2027, and relevant Annex I product duties from 2 August 2028. Commission amendment notice. | The original high-risk months are supported by the current notice. Add the other dates and actor-specific duties in section 4; delaying high-risk rules does not delay every AI obligation. |
| California SB 53 — Transparency in Frontier Artificial Intelligence Act | Enacted in September 2025 and effective 1 January 2026. Addresses frontier AI developers, safety-framework disclosure, certain critical safety incidents, and whistleblower protections. Duties differ by the statutory developer category. Governor's signing announcement, Senate confirmation of effective date, 2026 government summary. | Routing to a frontier model does not by itself establish that the operator is a covered frontier developer. Replace the unsupported description of “verified public transparency” with the actual disclosure and incident duties. |
| OSFI E-23 — Model Risk Management (2027) | Final Canadian supervisory guideline published 11 September 2025, effective 1 May 2027, for federally regulated financial institutions, including relevant foreign branches. Covers AI/ML and third-party models on a proportional, risk-based basis. Final guideline. | Support financial clients' model inventories, assigned ownership, independent review, approval, change control, monitoring, and decommissioning evidence. It is not a requirement imposed on every Canadian inference server. |
Evidence limitation for ISO: the public descriptions establish purpose and scope. The full standards were not accessed, so this document does not claim a verified clause-by-clause ISO control mapping.
2. Establish applicability before selecting an enforcement policy
OneVir's legal role cannot be determined just from “local inference”, “AI gateway”, or the model name. Record the deployment facts that the cited instruments use:
| Fact to establish | Why it changes the applicable duties |
|---|---|
| Market, establishment, and where outputs are used | EU AI Act Article 2 covers specified EU actors and certain non-EU providers/deployers whose system output is used in the Union; it also contains exclusions. Personal non-professional use is treated differently from professional deployment. Article 2. |
| Role in the value chain | Model providers, AI-system providers, deployers, and component suppliers have different duties. Rebranding or substantially modifying a high-risk system, or changing its purpose so that it becomes high-risk, can change the responsible actor. Article 25, GPAI provider duties, Article 53. |
| Purpose and effect of the application | Recruitment, credit, education, biometrics, and health-related uses can trigger specific duties. A generic chat endpoint is insufficient evidence that every request is a legally high-risk application. Commission risk categories, Colorado consequential-decision categories. |
| Public service versus internal use | China's generative-AI measures cover services offered to the public in mainland China and expressly exclude specified development/use that does not provide such a public service. The provider definition includes programmable interfaces. CAC measures, Articles 2 and 22. |
| Data types, children, and regulated clients | Data protection and sector rules have independent scope. Establish controller/processor relationships, recipients, and actual data flows. GDPR application, HHS cloud guidance, FTC COPPA guidance. |
OneVir application: bind the operator-approved purpose and data restrictions to authenticated applications or principals. A model's classification of a prompt, or a client-supplied label alone, is not proof of legal applicability. This is an implementation consequence of needing deployment context and enforceable authorisation, not a new legal classification rule. NIST AI RMF, OWASP object-level authorisation.
3. Additional global laws and regulatory regimes
The following are deployment-specific additions to the original six. “In force” does not mean “applicable to every OneVir installation”. Future commencement dates and sector limitations matter.
| Jurisdiction / instrument | Published duties and current status | OneVir relevance and boundary |
|---|---|---|
| EU / EEA — GDPR | In-scope processing requires lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy, storage limitation, and security. International transfers need an applicable mechanism. Commission principles, international transfers. | Apply restrictions to prompts, responses, files, embeddings, caches, and telemetry containing personal data. GDPR does not universally require all AI requests to stay inside the EU. |
| United Kingdom — UK GDPR / DPA 2018, amended by DUAA 2025 | The ICO confirms all DUAA data-protection provisions were in force by its 19 June 2026 update. Significant automated decisions can use broader lawful bases with safeguards; special-category data remains more restricted. ICO current explanation. | Support privacy and decision safeguards, but do not copy EU Article 22 unchanged into a UK policy. The application owns the consequential decision and user process. |
| United States — consumer protection and children's privacy | FTC enforcement includes deceptive AI capability claims. COPPA covers certain services collecting personal information from children under 13; its amended rule adds retention restrictions and parental-consent requirements for certain third-party disclosures. FTC AI enforcement, amended-rule announcement, COPPA scope. | Support claims with evidence. A child-facing client may need recipient restrictions, deletion, and age/parental-consent processes. COPPA is not an age-verification mandate for every internal inference API. |
| California — CCPA/CPRA and ADMT regulations | Regulations effective 1 January 2026 include risk assessments, cybersecurity audits, and automated decisionmaking technology rules. Section 7200 sets ADMT compliance for covered significant decisions at 1 January 2027. Scope and exemptions are specified. CalPrivacy regulations, operative text, section 7200. | Supply evidence for covered clients' privacy rights and risk assessments. Logs do not replace notices, access/opt-out handling, or applicable exceptions. These duties are distinct from SB 53. |
| Colorado — SB26-189 | Enacted 14 May 2026, repeals and reenacts the earlier SB24-205 provisions. Covered ADMT duties begin 1 January 2027: developer documentation and change notification; deployer notices; data rights and meaningful human review after adverse decisions; compliance records for at least three years. Enacted summary. | Preserve version/change evidence for covered decision applications. Do not describe the old SB24-205 deadline or impact-assessment regime as the current rule without accounting for its replacement. |
| United States — HIPAA | Covers relevant covered entities and business associates handling protected health information. HHS explains that maintaining encrypted ePHI can create business-associate status even without the decryption key. Agreements and safeguards remain necessary. HHS cloud guidance, contract requirements. | Restrict PHI to permitted recipients and support safeguards, incidents, and return/destruction duties. An inference product is not automatically “HIPAA compliant”; encryption alone does not establish compliance. |
| EU financial services — DORA | Applicable from 17 January 2025 to financial entities in scope. Covers ICT risk management, incident reporting, testing, and third-party risk; entities maintain ICT contractual-arrangement registers. EBA application notice, EBA scope explanation. | Financial clients may require operational/supplier evidence. Running OneVir does not itself make its operator a regulated financial entity or designated critical ICT provider. |
| China — Interim Measures for Generative AI Services (2023) | Effective 15 August 2023 for covered public services. Includes lawful training inputs, privacy, unlawful-content handling, complaints, and security assessment/algorithm filing for services with public-opinion or social-mobilisation attributes. Final measures, Articles 2, 7, 11, 14, 15, 17, 22. | Covered public/API services need specific content and operational controls. Filing/assessment are conditional, not blanket registration for private local models. Other data/security laws require separate scoping. |
| China — generated/synthetic-content labelling measures (2025) | Effective 1 September 2025: visible and metadata labelling duties for covered services and a supporting mandatory national standard. Article 9 conditionally permits output without visible labels, with recorded responsibilities and relevant logs for at least six months. Article 10 prohibits malicious label tampering/removal. Final measures, accompanying standard. | Preserve required labels through transformations/exports. Interface disclosure and file metadata have separate roles; a generic API header does not prove satisfaction of all labelling duties. |
| South Korea — AI Basic Act | In force 22 January 2026. Article 31 addresses prior notice for high-impact/generative AI products/services and generated-content labelling. MSIT differentiates providers from users and announced at least a one-year investigations/penalties grace period under this provision. MSIT transparency guidance. | Covered providers need notices/labels. Merely using AI tools for work or creative activities does not automatically trigger the provider duty. Enforcement grace is distinct from the law's commencement. |
| India — DPDP Act 2023 / Rules 2025 | Phased commencement: institutional provisions first, specified provisions one year after Gazette publication, and core processing/rights provisions 18 months after publication. The core provisions remain future at this research date. Official G.S.R. 843(E), Rules announcement. | Prepare for covered clients' notice, lawful processing, security, rights, and processor arrangements. Do not label all processing duties already enforceable in October 2026. Follow the Gazette schedule. |
| Brazil — LGPD / ANPD transfer regulation | Privacy and automated-decision rights; ANPD Resolution 19/2024 regulates international transfers and contractual mechanisms. The separate AI bill PL2338/2023 remains pending in the Chamber's status record. ANPD regulation, bill status. | Enforce authorised destinations and support applicable access/deletion/review processes. Do not present the AI bill as enacted duties or convert the LGPD review right into mandatory human review of every inference. |
| South Africa — POPIA | Section 71 restricts specified solely automated decisions with legal/substantial effects, subject to exceptions/safeguards; section 72 conditions transfers outside South Africa. Official Act. | Support permissible transfers and decision-process evidence. The responsible party/application must implement the statutory safeguards; routing metadata is insufficient. |
| Saudi Arabia — PDPL and implementing/transfer regulations | SDAIA's controller/processor guide covers lawful processing, rights, security, accountability, and cross-border rules. Transfer rules are distinct from AI ethics principles. Controller/processor guide, laws and regulations. | Apply covered clients' privacy/transfer restrictions. Do not infer blanket Saudi-only residency or equate an ethics document with all PDPL duties. |
| Canada — privacy obligations and regulator AI guidance | Regulators' GenAI principles address legal authority, appropriate purposes, necessity/proportionality, openness, accountability, safeguards, accuracy, and individual access. They explain privacy expectations, not a new omnibus AI statute. Joint regulator principles. | Support the client's applicable federal/provincial privacy law. Select that law and sector separately; E-23 adds financial-supervision expectations. |
California transparency update: the Governor announced further AI Transparency Act amendments, including AB2713 and SB1000, on 30 September 2026. Their consolidated operative provisions were not verified in this research; no exact additional threshold, gateway watermarking mandate, or effective date is asserted. A California public generative-media deployment needs that specific follow-up. Official enactment announcement.
4. EU AI Act: keep the different obligations separate
4.1 Current timeline
| Obligation category | Application milestone verified from current Commission sources |
|---|---|
| Original prohibited practices | 2 February 2025. Definitions and exceptions matter; a general “unsafe prompt” score is not the statutory test. |
| GPAI model-provider rules | 2 August 2025, with separate transition arrangements for earlier models. |
| Article 50 transparency | 2 August 2026. High-risk extensions do not postpone these duties. |
| New Omnibus prohibition on specified non-consensual intimate/sexually explicit content and CSAM-generating systems | December 2026, according to the Commission overview. |
| Annex III high-risk system rules | 2 December 2027. |
| Relevant Annex I high-risk product rules | 2 August 2028. |
Sources: Commission AI Act overview, current implementation timeline, Omnibus notice. Check transitional rules and exclusions for the actual deployment. The Omnibus also changed the earlier AI-literacy provision; do not carry forward old summaries unchanged.
4.2 Specific duties influencing gateway/inference design
| Published requirement | OneVir application and responsible boundary |
|---|---|
| Prohibited practices: Article 5 defines particular practices, including harmful manipulation/exploitation, social scoring, and specified biometric uses. Article 5. | Support restrictions on identified prohibited applications. Intent, thresholds, and exceptions need application context; a gateway cannot conclusively classify all legal uses from text alone. |
| High-risk risk management: Article 9 requires an iterative documented process and testing for intended purpose and foreseeable misuse. Article 9. | Preserve evaluation/deployment evidence and support restrictions derived from assessed risks. A model benchmark alone does not validate the complete application. |
| Human oversight: Article 14 includes understanding limitations, avoiding automation bias, disregarding/overriding/reversing output, and intervention or safe interruption. Article 14. | Cancellation/suspension can support oversight. The application must supply the competent human, understandable information, and meaningful decision authority. |
| Accuracy, robustness, cybersecurity: Article 15 includes fault resilience and appropriate protection against poisoning, adversarial inputs, and confidentiality attacks. Article 15. | Support measured performance, controlled updates, and security. The article does not specify universal accuracy percentages or prompt-filter thresholds. |
| High-risk logging: Articles 19 and 26(6) require retention of automatically generated logs under the actor's control for an appropriate period of at least six months, unless applicable law provides otherwise, particularly data-protection law. Article 19, Article 26. | Provide scoped retention/export. This does not require keeping every prompt/output forever or six-month retention for all non-high-risk chat. |
| Transparency: Article 50 distinguishes AI-interaction notices, provider duties for machine-readable synthetic-output marking/detection, and deployer disclosures for deepfakes/public-interest text. It includes exceptions and accessibility requirements. Article 50. | Preserve provenance/markings through transformations and support client notices. Metadata alone does not provide required visible, accessible disclosure. |
| GPAI model providers: Article 53 covers technical/downstream documentation, copyright policy, and a public training-content summary, with specified open-source exceptions. Article 53. | Keep supplier documentation available. Do not automatically assign a developer's training-summary obligation to an operator merely forwarding inference requests. |
5. Additional published standards and voluntary guidance
These references provide relevant practices even when a particular AI statute does not apply. Their inclusion does not make them mandatory worldwide.
| Reference | Verified scope and useful controls |
|---|---|
| ISO/IEC 23894:2023 | AI risk-management guidance for organisations developing, deploying, or using AI. Complements the management-system standards above. ISO abstract. |
| OWASP LLM Top 10, 2025 edition | Prompt injection, sensitive-information disclosure, supply chain, poisoning, improper output handling, excessive agency, system-prompt leakage, vector/embedding weaknesses, misinformation, and unbounded consumption. A security risk reference. Current list. |
| OWASP API Security Top 10, 2023 edition | Conventional API risks: authentication, object/function authorisation, resource consumption, SSRF, misconfiguration, and unsafe upstream API consumption. Publisher's list. |
| NCSC/CISA and international partners — Guidelines for Secure AI System Development | Secure design, development, deployment, and operation/maintenance; explicitly relevant to hosted models and external APIs. Guidelines. |
| Singapore — GenAI and Agentic AI governance frameworks | GenAI guidance addresses accountability, data, deployment, incidents, testing, security, and provenance. The Agentic AI framework launched 22 January 2026 covers responsible agent deployment and human accountability. GenAI dimensions, Agentic AI publication. |
| Japan — AI Guidelines for Business, version 1.2 | METI published version 1.2 in March 2026. Separate this guidance from Japan's AI promotion law, fully effective 1 September 2025, which establishes governmental measures and cooperation responsibilities. Neither is the EU high-risk regime. Current guidelines, Cabinet Office law outline. |
| Australia — Guidance for AI Adoption | Current guidance evolves the older Voluntary AI Safety Standard into six essential practices. Its implementation guidance covers accountability, risk, oversight, testing/monitoring, records, and supply-chain governance. Replacement explanation, implementation guidance. |
6. Published control families and their application to OneVir
Each source requires an outcome for a defined deployment or recommends a security practice. OneVir application translates that evidence into product responsibilities; it does not claim a regulator specified this exact implementation.
6.1 Request admission, identity, and data movement
| Control and published basis | OneVir application | Boundary |
|---|---|---|
| Authenticate callers and protect authentication flows. OWASP API2. | Authenticate inference/admin access as required by the deployment; protect credentials and apply revocation to subsequent access. | The model must not authenticate users through conversation. |
| Protect network transport and sensitive storage. OWASP recommends HTTPS for secure REST services and risk-appropriate cryptographic storage/key management. REST security, cryptographic storage. | Protect network API credentials/payloads and upstream connections; secure retained sensitive data and keep encryption keys protected. | Encryption supports security; it does not establish lawful processing, recipient approval, or complete compliance. |
| Authorise objects and privileged functions. OWASP API1, API5. | Scope model/provider access, stored files/conversations, cache/memory objects, and administration to the authenticated principal. | A valid key does not imply access to every tenant's objects. |
| Minimise and protect personal/sensitive information. GDPR principles, OWASP LLM02. | Apply approved restrictions before external disclosure and during storage/logging; use appropriate sanitisation/redaction and access control. | Redaction does not prove anonymisation, lawful processing, or contractual approval. |
| Control external recipients and transfers. Commission transfers, NCSC secure design. | Restrict eligible providers/regions to those approved for the client's data/purpose, including fallback and retry destinations. | Verify contracts, subprocessors, training use, retention, and processing locations with supplier evidence. A hostname alone does not establish them. |
| Prevent server-side request forgery. Validate destinations and restrict network access for input-derived server-side requests. OWASP API7. | Constrain remote resource/model fetching, media URLs, and permitted upstream endpoints where these paths exist. | Deployment network controls also matter; validating URL syntax is insufficient. |
| Bound resource/financial consumption. Published mitigations include size limits, quotas, timeouts, resource allocation, monitoring, and queue limits. OWASP LLM10. | Bound input/output size, concurrency/queues, duration, controlled agent iterations, and external spend. Include retries in aggregate limits. | Derive numbers from assessed capacity/client policy, not invented regulatory limits. |
6.2 Inference, retrieval, generated outputs, and tools
| Control and published basis | OneVir application | Boundary |
|---|---|---|
| Mitigate direct/indirect prompt injection. RAG/fine-tuning do not fully remove the risk. OWASP LLM01. | Treat user inputs, retrieved documents, files, and tool results as untrusted content; retain enforceable boundaries outside the model. | A prompt or detection model is not guaranteed prevention. |
| Keep secrets/security decisions outside system prompts. Prompts can leak and must not be relied upon for authorisation. OWASP LLM07. | Keep provider credentials and privileged policy enforcement in gateway/runtime security mechanisms, separate from model text. | “Never reveal this secret” is not secret protection. |
| Limit tool functionality, permissions, and autonomy. Execute in user context, mediate downstream authorisation, and require approval for high-impact actions as appropriate. OWASP LLM06. | Where OneVir hosts/mediates tools, restrict operations, validate calls/arguments, and preserve user context. | Tool-call JSON does not enforce an external agent's execution. The executor must enforce these controls. |
| Validate and safely handle outputs. Generated data can cause injection in downstream browsers, interpreters, databases, and commands. OWASP LLM05. | Validate structured outputs/arguments where consumed; encode/sanitise generated content in OneVir's UI and consumers. | Valid JSON does not make embedded commands, URLs, SQL, or HTML safe. |
| Enforce permission-aware retrieval and prevent cross-context leakage. Fine-grained permissions, partitioning, source validation, and monitoring are published mitigations. OWASP LLM08. | Preserve scope for embeddings, retrieval, memory, and semantic reuse. Similarity is not permission to reuse a stored answer. | Embeddings are not automatically anonymous; access/deletion depend on their content/use. |
| Assess misinformation and fitness for purpose. OWASP LLM09, EU Article 9. | Retain model/version/evaluation evidence and communicate supported-use limitations. | The application owns factual verification and consequential decisions. Fluency or a generated explanation is not validation evidence. |
| Apply the relevant content/disclosure policy. EU and China sources specify different scopes and duties. EU Article 50, China service measures. | Support the selected deployment's restrictions, refusal/escalation, and output labelling. | Do not invent one worldwide prohibited-topic list; restrictions, exceptions, and publication duties differ. |
6.3 Model lifecycle, evidence, and operational response
| Control and published basis | OneVir application | Boundary |
|---|---|---|
| Protect the model/software supply chain. Risks include untrusted models/components, licence restrictions, weak provenance, and outdated dependencies. OWASP LLM03. | Track origin, revision, integrity evidence, licence/permitted use; protect import/update paths and inference dependencies. | Download availability or an open licence does not prove safety or permission for every use. |
| Isolate untrusted imports and protect inference assets. NCSC recommends scanning/isolation when importing third-party models/weights and tracking/protecting models, data, prompts, and logs. Secure design, secure development. | Restrict access to worker/model assets and use suitable isolation for model import/loading; retain provenance and a way to restore known-good assets. | A file-format choice alone does not establish that an untrusted model or inference dependency is safe. |
| Guard against poisoning. Validate sources and integrity; assess data/model changes. OWASP LLM04. | Validate imported models and retrieval/memory ingestion under OneVir's control; investigate unexpected behaviour after changes. | A gateway cannot reconstruct supplier training provenance from outputs. |
| Inventory, validate, approve, and monitor models. E-23 expects risk-proportional governance, independent review, change control, and monitoring. OSFI E-23, sections B–D. | Supply version/change/evaluation/operation evidence; regulated clients may need review of model/provider/routing changes. | Health checks or generic benchmarks do not independently validate a financial model. |
| Log and monitor without unnecessary data exposure. NCSC operation/maintenance, GDPR principles. | Keep protected evidence of access, selection, policy decisions, changes, failures, and incidents; minimise raw content and provide authorised export/deletion. | Required duration/content vary. EU high-risk logs and Colorado compliance records are different record classes. |
| Maintain incident response and controlled release. Guidance calls for plans, security evaluation, limitations, secure defaults, and customer audit information. NCSC secure deployment. | Support model/provider isolation/suspension, evidence preservation, remediation, and controlled update activation. | Reporting recipients/deadlines are regime-specific; reporting and customer communications remain assigned organisational duties. |
7. Policy must survive routing, caching, and streaming
Sources do not mandate a particular pipeline. These are engineering consequences of applying their authorisation, privacy, output, and supplier restrictions to OneVir's serving paths:
- A fallback is another disclosure. Re-evaluate whether the next provider is permitted before sending data. A primary-provider failure does not remove transfer/recipient restrictions. Transfer rules.
- A cache hit is another access to stored data. Authorise the requester and reused material; preserve applicable retention/deletion. Similarity is not permission. This applies the published authorisation and leakage principles to caching. OWASP API1, OWASP LLM08.
- Released stream content has already been disclosed. If selected policy requires inspection before disclosure, a check after delivery cannot satisfy it. Choose buffering, staged release, or another control according to assessed risk; no source mandates one universal strategy. OWASP LLM02.
- Tool execution needs its own enforcement point. Preserve user scope and required approval at hand-off to the actual tool. OWASP LLM06 complete mediation.
- Logs, caches, and exports are also processing. Local inference does not remove privacy duties for other stores/telemetry recipients containing personal data. GDPR processing scope.
These identify where to apply a selected policy consistently. They do not require every customer to enable every filter, all data to stay local, or imply that a gateway alone makes a deployment compliant.
8. Responsibilities of the operator and consuming application
The cited regimes also require decisions/processes outside the inference request:
- Legal basis, purpose, notices, rights, and contracts: the responsible controller/operator establishes these and directs processors appropriately. GDPR roles, EDPB rights and processor assistance.
- Meaningful oversight and recourse: the client supplies human authority and the user process where required. Cancellation alone is insufficient. EU Article 14, Colorado duties.
- Governance and independent review: policies, owners, management review, validation, and approval are organisational activities. ISO 42001, OSFI E-23.
- Supplier facts and disclosures: obtain applicable documentation and verify operational/contractual facts. API compatibility does not establish provenance, processing location, or supplier compliance. EU Article 53, NCSC due diligence.
For implementation work, establish deployment facts, select cited obligations/practices, and inspect/test the affected OneVir paths. This research does not assign implementation status, invent acceptance thresholds, or assert certification. Refresh sources for new jurisdictions, regulated uses, or providers and before relying on future commencement dates.