Article 26 of the EU AI Act is the deployer's primary compliance layer. While Article 14 governs human oversight at the provider level, Article 26 specifies what an organisation must do when putting a high-risk AI system to work in the real world. For defence, intelligence, and security deployments, Article 26 obligations are not "nice-to-have" — they are structural requirements for legal, ethical, and operational deployment.
The 10 core deployer obligations in Article 26 cover: (1) use per the provider's instructions, (2) human oversight assignment, (3) monitoring of operation, (4) log retention, (5) information to natural persons, (6) FRIA cooperation, (7) data protection authority notification, (8) cooperation with fundamental-rights impact assessment, (9) quality-management link, and (10) informing the provider of serious incidents.
DEFONEOS provides deployer-side tooling that satisfies these requirements by construction: every deployer obligation maps to a substrate feature that the deployer activates at deployment-time. The deployer does not need to build compliance from scratch — they activate the relevant deployer-side compliance profile and pass the operator-naming configuration to it.
The deployer must use the system in accordance with the provider's instructions. DEFONEOS provides per-deployment usage instructions at /<deployment>/instructions-for-use per Article 13: intended purpose, accuracy/robustness/cybersecurity metrics, known risks, human-oversight requirements, lifetime/maintenance expectations, logging/interpretability protocol, performance metrics, limitations, deployer-Art-26 obligations, and support. These instructions are machine-readable: a deployer-side linter reads them and rejects configuration that violates the constraints.
The deployer must assign human oversight to natural persons with the required competence, training, and authority. DEFONEOS deployment templates include an "operator registry" that requires: (a) named natural person per role (HITL approver, HIC, kill-switch bearer, council voter, external auditor liaison), (b) verification of training attestation (each operator must have passed the DEFONEOS-OPS-101 module), (c) succession rules so that no role is vacant for >1 hour without a hot backup, (d) attestation that the role is within the human's competence and authority. The registry is SIGIL-signed and rotation is recorded.
The deployer must monitor the AI system's operation for risks and take appropriate action. DEFONEOS provides a live monitoring dashboard at /<deployment>/oversight/dashboard that surfaces: action rate vs baseline, intervention rate by operator (privacy-preserving aggregate), BFT vote tally, kill-switch-ready status, red-line trigger history, drift metrics on input distributions, performance decay against the baseline, and audit-trail integrity hash. Monitoring rules are configurable per deployment.
Deployers must keep the logs automatically generated by the high-risk AI system for at least 6 months. The logs must be sufficient to allow reconstruction of the system's operation and identification of risks. DEFONEOS provides three retention tiers: HOT (Redis-backed, 6 months, sub-second query), WARM (object storage, 5 years, query within minutes), COLD (WORM storage, indefinite, query requires SIGIL-signed request). Logs include: action ID, proposer, approver, BFT outcome, kill-switch status, red-line check, output, side-effects, external-actor interaction.
Where a deployer uses a high-risk AI system to make decisions affecting natural persons, the natural persons must be informed. DEFONEOS provides a "notice template" generator that produces: (a) the AI-identity disclosure, (b) a plain-language explanation of the decision and its effects, (c) the redress pathway, (d) the data-rights summary. The notice is delivered per deployment policy: in-product banner, email, paper notice, or in-person briefing. The notice can be pre-written by the deployer and approved by legal before templated.
Deployers of certain high-risk AI systems must support the provider's fundamental-rights impact assessment. DEFONEOS provides an "FRIA data pack" generator that packages the deployment-context data needed to complete an FRIA: scope (deployment region, affected persons, use case), human-oversight configuration, monitoring metrics, risk-treatment evidence, public-consultation summary. The pack is delivered to the provider within 30 days of FRIA initiation, and updated annually or on material change.
The deployer must inform the provider and, where applicable, the market surveillance authority of any serious incident. DEFONEOS detects and routes incidents through a "serious-incident pipeline": (a) detection at substrate level (red-line trigger, performance decay, anomalous output), (b) classification (per Article 3(49) definitions), (c) evidence packaging (full SIGIL chain + audit-trail snapshot + red-team-style reconstruction), (d) notification dispatch to provider + authority + regulator within 15 days (or 72h for critical incidents). The pipeline is auditable end-to-end.
Deployers must cooperate with competent authorities in any action they take in relation to the AI system. DEFONEOS provides a "regulator access protocol" at /<deployment>/regulator-access: regulators with proper authority can run a SIGIL-verified query against the deployment's audit trail, request evidence exports in 6 standard formats (SIGIL log, OSCAL, JSON-LD, CSV, PDF, XCCDF), and request suspension of action pending review. All access requests are SIGIL-logged at request-time.
Where the deployer operates in a regulated domain (medical, financial, defence, infrastructure), its quality-management system must interface with the provider's QMS. DEFONEOS provides a "QMS bridge" — a SIGIL-signed exchange between provider QMS and deployer QMS, with change-control governed by both sides. The bridge ensures that version updates, configuration changes, and serious incidents in either QMS propagate to the other with appropriate escalation.
When the provider releases a new version, fixes a red-line trigger, or issues a serious-incident note, the deployer must respond. DEFONEOS provides a "subscribe to provider notices" channel: signed notices flow to the deployer's compliance owner within 24h; deployment updates queue for review; and the deployer is reminded if it has not acted within the SLA. The pipeline is bidirectional — deployer-issued incident reports flow back up to the provider.
Use case: AI-assisted drafting of all-source intelligence products. Deployer obligations include: HITL approval for any product released externally; SIGIL audit trail for every product version; 6-month log retention; PII redaction before release; collaboration with the Information Commissioner's Office (UK) / national DPA.
Use case: AI-assisted identification of objects, persons of interest, vehicles, infrastructure. Deployer obligations include: HITL approval for any identification used in operational decisions; "identification confidence" disclosure to decision-makers; cross-deconfliction with other identification sources; kill-switch readiness; red-line check on named-person targeting.
Use case: AI-assisted threat scoring, early-warning analysis, anomaly detection. Deployer obligations include: HITL approval for any threat assessment used in operational escalation; FRIA completion for civil-impact assessments; human-oversight on threshold-setting; rights-of-challenge for assessed individuals; QMS integration with intelligence cycle.
Use case: AI-assisted cyber defence, signature detection, takedown of adversary infrastructure. Deployer obligations include: HITL approval for any offensive cyber action (BFT-council-bound); NCSC coordination for UK-sector takedowns; red-line check on civilian infrastructure; SIGIL audit-trail for every action; after-action review triggered automatically.
Use case: AI-assisted option generation for operational planning (non-targeting). Deployer obligations include: HITL review of every plan variant; SIGIL audit-trail for plan provenance; "advisory-only" labelling of all AI-generated variants; DPO engagement on data sources; separation of training data from operational data.
Use case: AI-assisted preparation of intelligence products for sharing with allied partners. Deployer obligations include: HITL approval with two-person (OIC + Legal) for every cross-border release; receiver-side attestation; SIGIL provenance for shared products; data-spillage detection; redaction protocol.
Use case: AI-assisted public information, queries, advisory support. Deployer obligations include: clear AI-identity disclosure; accessible explanation; equity review for service populations; FRIA completion (Art 27); DPO engagement for personal data; kill-switch readiness.
| # | Notice Type | Audience | Channel | Frequency |
|---|---|---|---|---|
| 1 | AI identity disclosure | All natural persons | Banner | First interaction |
| 2 | Decision rationale | Subject of decision | Receipt + redress link | Per decision |
| 3 | Explanation request pathway | Subject of decision | Web form | On request, ≤30 d |
| 4 | Redress pathway | Subject of decision | Web form + post | On request |
| 5 | Data-rights summary (UK GDPR Art 13/14) | Subject of processing | Web + paper | On collection |
| 6 | Human-review pathway | Subject of automated decision | Receipt + form | With decision |
| 7 | FRIA public summary | Affected community | Web (anonymised) | Per FRIA cycle |
| 8 | Serious-incident notice | Affected persons | Direct + web | Within 15 days |
| 9 | Provider change notice | Affected persons + deployer | Web + email | Per change |
| 10 | Opt-out pathway | Persons who object to AI assessment | Web form | Always available |
| 11 | Data-deletion request | Data subjects | Web form | On request, ≤30 d |
| 12 | Compensation pathway | Persons harmed by AI decision | Web form + legal | On harm |
| 13 | Council-vote notification | Affected parties (where publishable) | Web | 30 days post-vote |
| 14 | Kill-switch notification | Operator + HIC + DPO | Console + SMS + paper | Within 2 seconds |
A Deployer Compliance Profile (DCP) is a JSON document that captures the configuration of DEFONEOS for a specific deployment. It maps each Article 26 obligation to the deployer-side configuration that satisfies it. The DCP is SIGIL-signed and versioned. Deployer-side linters can verify a DCP meets compliance profile requirements.
The DCP has the following structure:
{
"deployment_id": "defoneos-mod-cybersec-2026-07",
"provider": "CSOAI LTD, UK 16939677",
"version": "4.7.2",
"provider_compliance_profile": "CDef-A26-v3",
"deployer": {
"name": "Ministry of Defence (UK example)",
"country": "GB",
"regulator_authority": "ICO + NCSC + Defence-AI-Forum"
},
"obligations": {
"o1_use_per_instructions": {"verified": true, "linter": "pass", "evidence_ref": "/logs/o1-2026-07-01.json"},
"o2_human_oversight_assignment": {"verified": true, "registry_ref": "/registry/operators-2026-07.json"},
"o3_monitor_operation": {"verified": true, "dashboard_url": "/dashboard"},
"o4_log_retention_6mo": {"verified": true, "retention_tier": "HOT", "retention_period_days": 180},
"o5_inform_natural_persons": {"verified": true, "notice_template_ref": "/templates/notice-v3.html"},
"o6_cooperate_with_fria": {"verified": true, "fria_pack_ref": "/fria/2026-Q3.json"},
"o7_serious_incident_notification": {"verified": true, "pipeline_url": "/serp/v2"},
"o8_cooperate_with_authorities": {"verified": true, "regulator_access_url": "/regulator-access"},
"o9_qms_bridge": {"verified": true, "bridge_ref": "/qms/bridge-2026.json"},
"o10_change_notice_subscribe": {"verified": true, "subscribe_ref": "/provider-channel/2026"}
},
"deployment_categories_active": ["intel_prod", "cyber_def", "decision_support"],
"categories_permitted": ["intel_prod", "cyber_def", "decision_support", "civil_public_use"],
"categories_prohibited": ["target_kinetic", "named_person_targeting", "civil_harm_optimisation"],
"signed_by": "Ed25519:defoneos-dcp-signer-v1",
"issued_at": "2026-07-01T00:00:00Z",
"valid_until": "2027-07-01T00:00:00Z"
}
| Framework | Article / Clause | DEFONEOS Mapping |
|---|---|---|
| EU AI Act | Article 26 | 10 obligations + 7 categories + 14 notices + DCP |
| EU AI Act | Article 13 (instructions for use) | Per-deployment instructions + linter |
| EU AI Act | Article 14 (human oversight) | Operator registry + council + kill-switch |
| EU AI Act | Article 27 (FRIA for deployers) | FRIA data pack generator |
| GDPR | Article 13 + 14 (information to data subjects) | Notice templates 5, 10 |
| GDPR | Article 22 (automated decisions) | Notice templates 6, 10 |
| GDPR | Article 33 (data breach notification) | Serious-incident pipeline |
| UK GDPR + DPA 2018 | Same as GDPR | Same as EU |
| ISO/IEC 42001 (AI Management) | Annex A.9 (AI system operation) | DCP + monitoring + change-notice |
| ISO/IEC 27001 (InfoSec) | A.8 (asset management) + A.16 (incident) | Log retention + serious-incident pipeline |
| NIST AI RMF | MANAGE 4 (AI system operation) | 10 obligations + DCP |
| NATO AI Strategy | Responsible AI Use Principles | 10 obligations + council + kill-switch |
7 personas · 5 tiers · 30-second signup · free 30-day sandbox for regulators and end-users.
Sign up · Ed25519-signed receipt → For Defence Primes For Regulators (Free) Series A — £45-90M Round