Achieving EU AI Act Compliance with CogNEXUS

The deadline didn't disappear. It moved — and got more serious.

If you deploy AI agents that touch anything consequential — credit, hiring, healthcare, fraud, access to essential services — the EU AI Act's high-risk obligations are coming for you. The only thing that changed in 2026 is when.

The Annex III high-risk obligations were originally scheduled to apply from August 2, 2026. On May 7, 2026, the Council and Parliament reached provisional agreement on the Digital Omnibus on AI, postponing Annex III obligations to December 2, 2027 (Annex I, product-embedded systems, move to August 2, 2028). Those dates bind once the Omnibus is published in the Official Journal, expected July 2026.

A later deadline is not a reprieve. It's a window — and the deployers who use it to build the compliance evidence base will be the ones who get to ship agentic systems with confidence while everyone else is still arguing about what "appropriate logging" means.

That's the compliance gap CogNEXUS was built to close.

What CogNEXUS actually is

CogNEXUS is the Decision Layer for Autonomous Systems — a runtime governance layer that sits between your orchestrators and the agents they deploy. Every agent decision routed through CogNEXUS is:

• policy-cleared — evaluated against versioned, signed policy bundles,
• cryptographically signed — sealed into a hash-chained, Ed25519-signed audit log, and
• fully auditable — reconstructable offline, years later, with zero trust in our servers.

The honest version of the claim, straight from our EU AI Act control-mapping document:

Running agents through CogNEXUS produces the records and controls that Articles 12, 9, and 10 require. CogNEXUS does not make a deployer compliant in isolation. Deployers remain responsible for their own risk classification, data governance upstream of the CogNEXUS boundary, and obligations that arise from the nature of their high-risk system.

We map controls to obligations. You stay responsible for your system. That boundary is the whole point — and it's the difference between a vendor selling you a green checkmark and a vendor handing you defensible evidence.

The three Articles that matter for agents — and how CogNEXUS answers each

The Act is long. For teams operating autonomous agents, three obligations do most of the work: record-keeping (Art. 12), risk management (Art. 9), and data governance (Art. 10).

Article 12 — Record-Keeping (Logging)

What it requires: high-risk systems must technically allow automatic recording of events over the system's lifetime — including, for Art. 12(3) scope, the period of each use, the input data, and the persons who verified results. Article 19 requires providers to retain logs for at least six months.

What CogNEXUS does:

• Every decision is sealed as an audit_leaves row synchronously inside the API response — the endpoint does not return until the leaf is committed to Postgres.
• Each leaf records: timestamp, agent DID, action, target, payload SHA-256 (not the raw payload), outcome, contributing guard votes and findings, policy bundle version, resolution policy version, and reviewer identity on human write-backs.
• Leaves are hash-chained (prev_leaf_hash) and Merkle-batched into audit_seals every 60 seconds or 500 leaves.
• Every leaf and seal is Ed25519-signed; public keys are stored separately and bundled into the evidence export.
• Append-only is enforced at the database layer: the application role holds INSERT + SELECT only — UPDATE and DELETE are revoked.
• A fail-closed audit circuit breaker: if the audit log becomes unwritable, the Decision API returns 503 rather than proceeding without a record.
• A 7-year retention floor — well beyond the six-month statutory minimum — declared in the compliance bundle and machine-checked at activation.

The kernel of this audit chain already ships today in the open-source SDK, hash-chained and signed:

pythonfrom cognexus.events import read_recent_events

# Detections are written to an append-only JSONL trail.
# No raw user text is ever stored — only a SHA-256 hash and a
# 96-character redacted preview.
rows = read_recent_events(user_id=42, limit=20)
# [{"ts": "...", "kind": "prompt_injection", "threat": "high", ...}, ...]

And the assessor-facing verification is offline and zero-trust — you don't have to take our word for any of it:

bash# Recompute leaf hashes, chain linkage, Merkle roots, and verify
# every signature against bundled public keys — no network, no server trust.
cognexus audit verify ./audit-export/

# Produce an assessor-ready evidence directory for a time window
GET /api/v1/audit/export?from=2026-10-01&to=2026-11-30

# One command to generate the full EU AI Act evidence pack
cognexus audit export --profile eu-ai-act

The tamper-evidence test — and it's a required acceptance test in our P0 plan, not a marketing line: edit a single byte in any leaf, and audit verify fails, naming the exact sequence number that broke.

Article 9 — Risk Management System

What it requires: an established, documented, iterative risk-management process — identify and analyze known risks, estimate and evaluate them, adopt appropriate measures, and test before deployment.

What CogNEXUS does:

• Versioned, signed policy bundles capture identified risks as enforced rules. Each bundle is an immutable, Ed25519-signed artifact that cannot be deployed without a valid signature from a registered team key (unsigned bundles are rejected at 422).
• Bundle promotion is audited: promote_bundle events are sealed as audit leaves, producing a tamper-evident policy change history in the same log as operational decisions.
• Shadow evaluation: candidate bundles run against live traffic off the request path with zero added latency; divergence statistics accumulate before any production promotion. Mean time to detect a policy regression: < 15 minutes.
• Kill switch + fail-closed semantics: a global panic mechanism halts all agent-mediated decisions instantly, and enforcer exceptions default to deny.
• Human review queue: decisions with a review outcome are captured in the audit log with reviewer identity on write-back — the oversight loop is itself machine-audited.

The kill switch and fail-closed behavior aren't roadmap items — they're in the published package today. The destructive-action guard is the layer that was missing in the April 2026 incident where an AI coding agent wiped a production database in nine seconds despite a prompt that forbade it:

pythonfrom cognexus import screen_action, ActionSeverity

result = screen_action("DROP DATABASE production;")
print(result.is_destructive)   # True
print(result.severity)         # ActionSeverity.CRITICAL

# The guard is FAIL-CLOSED: if a rule itself raises on adversarial
# input, the result escalates to CRITICAL — a buggy rule can never
# silently let a destructive operation through.
if result.severity is ActionSeverity.CRITICAL:
    refuse_and_alert()

And the kill switch — cooperative cancellation plus an auto-tripping global panic flag — gives you the "stop everything now" control that Article 9 risk management implies:

pythonfrom cognexus import raise_if_killed, trip, trip_global, AgentKilledError

def long_running_agent(run_id):
    try:
        for step in plan:
            raise_if_killed(run_id)   # halts at the next safe point
            do_work(step)
    except AgentKilledError as kex:
        log.warning("Run %s killed: %s", run_id, kex.reason)

# Programmatic trip from an anomaly detector
trip(run_id=42, reason="3 destructive signals in 30s", raise_after_trip=False)

# Process-wide red button for systemic failures
trip_global(reason="incident response: model behaviour anomaly")

If the destructive-action guard trips 5 CRITICAL signals inside 60 seconds (both configurable), the global panic flag raises automatically — every running and future agent stops until an operator clears it. That's a documented risk-mitigation measure, not an aspiration.

Article 10 — Data and Data Governance

What it requires: training, validation, and testing data meet quality criteria; bias examination is applied; data provenance is documented; special-category data is handled appropriately.

What CogNEXUS does today (and what it honestly doesn't):

CogNEXUS P0 addresses Article 10 at the inference boundary — and we say so explicitly rather than overclaiming:

• Payload hashing at the boundary: leaves store payload_sha256, not raw payloads — preventing the creation of an unconsented PII lake.
• Data-source provenance: context_items in a decision request carry provenance metadata, recorded in the audit leaf.
• Policy-rule lineage: rules generated from scanned compliance documents carry source_refs linking back to the originating document. (In the dashboard, these surface under Guidelines after a Compliance Monitor scan.)
• Special-category data stopgap: the EU AI Act bundle includes rules that flag payloads matching special-category patterns for human review.

This is the document-derived policy enforcement you can wire into your own app today:

pythonfrom cognexus import (
    configure, load_client_policy_rules,
    screen_client_policy, should_block_policy,
)

configure(api_key="cnx_…")          # fetch tenant rules from the dashboard
rules = load_client_policy_rules()  # rules derived from scanned policy docs

report = screen_client_policy(user_message, source="chat", rules=rules)
if should_block_policy(report):
    raise PermissionError("Violates organizational policy")

The declared gaps (we publish these): full Article 10 coverage for upstream training data and model registries requires the privacy-guardian agent (P1 roadmap) for runtime PII detection, consent verification, and special-category handling beyond pattern matching, plus model-registry lineage (P2) for a provenance chain from training data through model versions to deployed decisions. Until then, the boundary is stated explicitly — because a compliance document that hides its own gaps is worse than useless to an assessor.

A worked example: governing an agent end-to-end

Here's what "policy-cleared and auditable" looks like in code you can run right now with pip install cognexus. The same four compliance layers that govern a single agent are the inline enforcers behind the Decision API:

pythonfrom cognexus import (
    augment_system_prompt, evaluate_system_prompt,
    screen_user_input, should_block,
    screen_agent_action, raise_if_killed, AgentKilledError,
)

# 1. Static defence — grade the system prompt A–F BEFORE deployment
system = augment_system_prompt("You are a helpful customer support agent.")
report = evaluate_system_prompt(system)
assert report.grade == "A"      # 100, no missing controls

# 2. Runtime input screening — what the USER sends
result = screen_user_input(user_message, source="chat")
if should_block(result):
    raise PermissionError(f"Injection blocked: {result.explanation}")

# 3. Output guard + kill switch — wrap every tool call the agent makes
try:
    for step in plan:
        raise_if_killed(run_id)
        screen_agent_action(
            step.payload, run_id=run_id, user_id=user.id,
            agent_id="my-agent", source=step.tool,
        )
        execute(step)
except AgentKilledError as kex:
    mark_run_killed_in_db(run_id, kex.reason)
    raise

Four layers — static prompt grading, input screening, output/destructive-action guarding, and a kill switch — each emitting an audit event. All of it pure-Python, deterministic regex, zero LLM calls, zero network access, under 5 ms per input. That determinism matters for an assessor: the same input always produces the same verdict, and the verdict is reproducible offline.

The evidence pack: what your assessor actually receives

Compliance isn't a conversation; it's a folder of artifacts that survives scrutiny. cognexus audit export --profile eu-ai-act produces an assessor-ready directory, every artifact reproducible from a staging tenant with synthetic traffic:

For the assessment, we pre-generate 10,000+ decisions spanning allow, deny, and review outcomes across all three inline enforcers (Prompt Defender, Destructive-Action Guard, Client Policy Enforcement) on our staging tenant, MoreStore — a CogNEXUS Labs product built on the engine.

Why move now instead of in 2027

The CogNEXUS plan targets a signed external readiness letter by December 2026 — a full year ahead of the December 2, 2027 activation:

• Phase 1 (Jun–Jul 2026): mapping document finalized, evidence pack generated, internal dry-run and remediation list.
• Phase 2 (Q3 2026): assessor engaged and scoped. Assessor firms book 4–6 weeks out — engaging by September protects the Q4 window.
• Phase 3 (Q4 2026): external readiness assessment on the staging tenant with synthetic sealed logs; readiness letter targeted for December 2026.
• Phase 4 (2027): privacy-guardian ships, closing the declared Art. 10 gap; evidence refreshed well ahead of activation.

For a deployer, the math is simple. If your governance layer already produces signed, offline-verifiable records today, you adopt agentic systems on that evidence base now — instead of spending 2027 retrofitting logging into a system that was never designed to remember what it did.

The honest summary

• Article 12: Full coverage in P0 — hash-chained, Merkle-sealed, Ed25519-signed, append-only-enforced, fail-closed, 7-year retention, offline-verifiable.
• Article 9: Full coverage in P0 — signed policy bundles, audited promotion, shadow evaluation, kill switch, fail-closed defaults, machine-audited review queue.
• Article 10: Partial in P0 (boundary payload hashing, provenance, rule lineage, special-category flagging); declared P1/P2 items close the rest.

CogNEXUS doesn't promise to make you compliant by installing a package. It promises something more useful: the records and controls the Act requires, generated automatically as a byproduct of running your agents — and verifiable by anyone, offline, without trusting us.

bashpip install cognexus      # the open-source guards + audit chain, today
cognexus quickstart       # local chat GUI to see the layers in action

This post summarizes the CogNEXUS EU AI Act control-mapping document (v0.2, draft for assessor engagement) and the published cognexus SDK (v0.2.21). Regulatory dates reflect the Digital Omnibus provisional agreement of May 7, 2026, and bind upon Official Journal publication. Nothing here is legal advice; deployers remain responsible for their own risk classification and obligations.