EU AI Act Gap Analysis Framework

a. The obligation in plain English

Article 12(1) requires that "high-risk AI systems shall technically allow for the automatic recording of events ('logs') over the lifetime of the system." Article 12(2) specifies these logs must enable "a degree of traceability of the AI system's functioning that is appropriate to the intended purpose." In practice this means every decision the system makes must be reconstructable after the fact, and the record must be trustworthy.

b. What "compliant" actually looks like

1. Logs are generated synchronously with the decision, not reconstructed after. The logging call is on the critical path; if logging fails, the decision does not ship.
2. Each log entry is cryptographically bound to its predecessor (hash-chain, Merkle tree, or equivalent) so any deletion, insertion, or modification is detectable by an independent party.
3. Logs are canonicalized before signing using a deterministic serialization (RFC 8785 JCS or equivalent), so two verifiers produce identical hashes.
4. Log write permissions are separated from read permissions, and no role — including platform administrator — can retroactively edit an entry without leaving a detectable signature break.
5. Retention spans the system lifetime plus the regulatory tail (typically 6–10 years for high-risk domains), with integrity verifiable across the full window.
6. Each entry contains the minimum reconstruction set: input hash, model/policy version, decision, confidence, actor identity, timestamp (monotonic + wall clock), and upstream correlation ID.
7. An independent third party can verify the chain given only a public verification key and the log export — no access to your infrastructure required.

c. Scoring rubric

d. Common gap patterns

• Application logs written to Datadog/Splunk/Elastic/CloudWatch are mutable by anyone with platform admin rights — not Article 12 compliant regardless of retention settings.
• Decision logs generated by a post-hoc scraper that reads transaction tables. The decision happened; the "log" is a downstream interpretation. A regulator will reject this.
• Signed logs using json.dumps(sort_keys=True) instead of a canonicalization scheme. Two runtimes produce different bytes; signatures diverge; audit fails.
• "Immutable" S3 buckets with object-lock configured for 90 days but no hash chain. Deletion is prevented, silent replacement is not.
• Log retention set at the logging platform's default (30–90 days). High-risk regulatory tails require years.
• Correlation IDs exist at the HTTP layer but not at the decision layer — you can find the request, not the decision path inside it.
• Signing keys rotated without publishing prior public keys; historical signatures become unverifiable.
• Merkle roots computed but never published externally. "Trust us, the root is correct" is not independent verifiability.

e. Diagnostic questions

Check each box only if you could produce the evidence to an auditor today.

f. How to close the gap

a. The obligation in plain English

Article 14(1) requires high-risk AI systems be "designed and developed in such a way … that they can be effectively overseen by natural persons during the period in which the AI system is in use." Article 14(4) specifies that overseers must be able to "fully understand the capacities and limitations of the high-risk AI system," "correctly interpret the high-risk AI system's output," decide not to use it, "intervene on the operation of the high-risk AI system or interrupt the system," and do so in "real time."

b. What "compliant" actually looks like

1. A human in the chain of control has the authority and the technical means to halt a decision before it executes — not just observe it after the fact.
2. Outputs are surfaced in human-interpretable form, with the confidence, the alternatives considered, and the factors that drove the decision.
3. An override action is a first-class operation that is logged, attributed to the overseer, and joined to the decision record.
4. There is an explicit approval workflow for high-consequence decisions, with the threshold documented and enforced in code (not in a runbook).
5. Anomaly detection surfaces unusual behavior to the overseer proactively — overseers cannot be expected to review every decision.
6. The overseer has training documentation specific to this system covering known failure modes, typical output ranges, and the specific signals that indicate the system is operating outside its intended scope.
7. The kill switch is tested on a documented cadence and the test results are retained.

c. Scoring rubric

d. Common gap patterns

• The "human in the loop" is a reviewer who sees decisions on a dashboard after they've already been executed. This is human observation, not Article 14 oversight.
• Approval workflow exists but is routinely auto-approved because the queue is too large for the staffing. Compliance theater.
• The override mechanism exists in theory (a config flag, a feature toggle) but has never been exercised in production. It will not work when you need it.
• Anomaly detection fires into a Slack channel no one monitors. No SLA, no escalation, no on-call.
• The training document for overseers is the public product page. Overseers don't understand the system's failure modes well enough to identify them when they occur.
• Approval clicks are attributed by session cookie, not by cryptographic signature. Anyone with access to the operator machine is "the overseer."
• Kill switch requires filing a ticket and waiting for an engineer. By definition, not real-time.
• Override events are logged in the operator console but not joined to the decision chain — reconstruction after an incident requires correlating two separate systems.

e. Diagnostic questions

f. How to close the gap

a. The obligation in plain English

Article 15(1) requires high-risk AI systems be "designed and developed in such a way that they achieve an appropriate level of accuracy, robustness and cybersecurity, and perform consistently in those respects throughout their lifecycle." Article 15(4) specifies they must be "resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities." Article 15(5) requires fail-safe behavior: the system must either handle errors gracefully or refuse to operate.

b. What "compliant" actually looks like

1. The system has a documented adversarial threat model with explicit attack classes, not a generic "we follow OWASP" statement.
2. There is a deterministic enforcement layer between input and inference that cannot be bypassed by prompt content, escalation patterns, or manipulation of upstream systems.
3. The enforcement layer is itself resilient — it fails closed (reject) rather than failing open (allow), and enforcement errors are treated as security events.
4. Accuracy is measured on a published benchmark with a documented refresh cadence, and degradation triggers a release block.
5. Adversarial testing is continuous, not a once-a-year penetration test. New attack vectors are added to the test corpus as they are discovered.
6. The enforcement logic is pure / side-effect-free where possible, so its behavior can be unit-tested exhaustively and formally reasoned about.
7. Dependency and supply-chain integrity is attested (SBOM, build provenance, pinned dependencies with hash verification).
8. There is a documented rollback path to a last-known-good model and policy version, with RTO measured in minutes, not hours.

c. Scoring rubric

d. Common gap patterns

• "We use an LLM to check whether the LLM's output is safe." LLM-as-governance-of-LLM. The governance layer has the same failure modes as the thing it is governing. Auditors will correctly identify this as circular.
• Enforcement implemented as a system_prompt instruction to "refuse unsafe requests." Prompt-layer safety is a performance improvement, not a compliance control.
• Accuracy benchmarks run once, never refreshed. The benchmark is the training distribution. Production drift is invisible.
• Adversarial test suite is hardcoded with the attack vectors discovered in 2023. Today's attacks don't appear in the test set.
• Enforcement layer accepts input and "usually" blocks disallowed actions, but a try/except in the wrong place fails open. The rule "enforcement errors = reject" is not implemented.
• Model and policy versions are not pinned to releases. Production silently rolls to a new version when the vendor updates; you cannot reproduce a decision from last month.
• No SBOM. No build provenance. The binary you deployed is not verifiably the binary your CI built.
• Rollback procedure is "redeploy from the release tag" but has never been exercised under time pressure. It will take a day when you need 10 minutes.
• Input normalization (Unicode NFKC, homoglyph collapse, zero-width strip) happens after pattern matching, not before. Attack prompts using homoglyphs or zero-width characters bypass the regex layer.

e. Diagnostic questions

f. How to close the gap

a. The obligation in plain English

Article 26 requires deployers of high-risk AI systems to "monitor the operation of the high-risk AI system on the basis of the instructions for use" and to "inform the provider or distributor … where they have reason to consider that the use in accordance with the instructions for use may result in [the system] presenting a risk." Article 27 requires, for specified deployers, a Fundamental Rights Impact Assessment (FRIA) describing "the categories of natural persons and groups likely to be affected," "the specific risks of harm likely to have an impact" on them, and the "measures to be taken in case of the materialisation of those risks."

b. What "compliant" actually looks like

1. A formal FRIA document exists with named owners, categorized affected populations, identified rights at risk, and mitigation measures — and it is versioned, not a one-time artifact.
2. Post-market monitoring is a continuous telemetry pipeline, not a quarterly report. Drift, disparate impact, and incident patterns are surfaced in near-real-time.
3. There is a documented incident reporting pathway to the provider (and to the competent authority where required) with response SLAs.
4. Disparate-impact metrics are computed per protected-attribute cohort where lawful and relevant, and degradation triggers a review.
5. The telemetry feeding the FRIA and post-market monitoring is itself tamper-evident — you cannot monitor compliance with forgeable data.
6. Monitoring scope includes upstream dependency changes (model updates, policy updates, vendor changes) because they can invalidate the FRIA's assumptions.
7. Incidents trigger a re-assessment of the FRIA, not just a patch. The FRIA is a living document whose version history is part of the compliance record.

c. Scoring rubric

d. Common gap patterns

• FRIA produced once for the audit, never updated. When the model or policy changes, the FRIA's assumptions are silently invalidated.
• Post-market monitoring confused with product analytics. DAU and click-through are not Article 26 signals.
• Drift monitoring exists for the model's technical metrics (loss, perplexity) but not for the decision-level metrics (approval rate, denial rate by cohort, override rate).
• Incident reporting is "file a Jira ticket." No SLA, no external routing, no evidence the ticket reached the provider.
• Disparate-impact metrics are computed once during initial validation and never again. Populations drift; your fairness claims go stale.
• The monitoring dashboard pulls from the same mutable observability platform that fails Article 12. Auditor challenges one, challenges both.
• The FRIA is owned by Legal with no engineering counterpart. The mitigation measures described are not actually implemented in code.
• Incidents are tracked by severity (P1/P2) but not by rights impacted. The categorization a regulator wants is not in the data.

e. Diagnostic questions

f. How to close the gap