EU AI Act Compliance for Engineering Teams: Risk Classification, Technical Documentation, and Building Audit-Ready AI Systems Before August 2026

August 2, 2026 is not a soft target. It is the date when EU AI Act obligations for high-risk AI systems become fully enforceable, with penalties reaching €35 million or 7% of worldwide annual turnover. That exceeds GDPR penalty caps.

The realistic path to compliance from a baseline of nothing takes 32 to 56 weeks. If you are reading this in April 2026, you have roughly 14 weeks. That is not enough time to start from scratch, but it is enough time to ship the critical engineering controls if you understand what actually needs to be built.

This article focuses on the engineering implementation. It does not interpret law. If you need legal counsel, get it. What follows is what your team needs to build.

What the EU AI Act Actually Requires from Engineering Teams

The EU AI Act establishes a tiered risk system. Most of the compliance burden, including all the documentation, logging, and oversight requirements, applies to high-risk systems. Prohibited systems (a much smaller category) must be shut down entirely.

For engineering teams, the practical obligations for a high-risk system are:

1. Technical documentation per Annex IV
2. Logging and traceability for every consequential AI decision
3. Accuracy, robustness, and cybersecurity measures
4. Human oversight mechanisms built into product architecture
5. Transparency toward deployers and users
6. Conformity assessment before market placement

“General purpose” AI systems and low-risk systems have lighter obligations. The first question to answer is whether your system is high-risk.

Determining Your Risk Classification

The high-risk annex (Annex III) lists specific application domains. These are the categories that catch engineering teams by surprise:

Domain	Examples that qualify
Employment	CV screening, interview scheduling AI, employee performance monitoring, task allocation
Access to education	Automated admissions scoring, exam proctoring with AI flagging, outcome prediction
Access to essential services	Credit scoring, insurance risk assessment, social benefit eligibility
Biometrics	Facial recognition, emotion inference (mostly prohibited), remote ID
Critical infrastructure	Safety components in energy, transport, water, health
Law enforcement	Risk assessment tools used by authorities
Migration and border	Document verification, risk assessment for entry
Administration of justice	Legal outcome prediction tools

Two things engineers commonly miss: first, the classification is based on the intended use case, not the underlying model. A GPT-4o wrapper used for CV screening is high-risk. The same model used to generate marketing copy is not. Second, if your product is a general-purpose platform and a customer uses it for a high-risk purpose, the downstream deployer carries compliance obligations, but you may still need to provide technical documentation and conformity support.

If you are in a gray area, the EU AI Office has published guidance, and the regulation text itself is the authoritative source. What you cannot do is assume you are out of scope without going through the classification exercise explicitly.

A Classification Checklist

Before you start building compliance infrastructure, run through this check:

interface RiskClassificationResult {
  isHighRisk: boolean;
  applicableAnnexIIIDomains: string[];
  rationale: string;
  reviewedAt: Date;
  reviewedBy: string;
}

// Document this in your Annex IV technical file.
// It needs to be a durable record, not a Slack message.
const classifySystem = (systemDescription: {
  intendedPurpose: string;
  targetDomain: string;
  decisionOutputType: "recommendation" | "autonomous-decision" | "filtering" | "ranking" | "scoring";
  affectedPopulation: string[];
}): RiskClassificationResult => {
  // Your classification logic, driven by Annex III categories.
  // This function should be version-controlled and reproducible.
};

The key output is not the boolean. It is the documented rationale that an auditor can review. Forty percent of enterprise AI systems have unclear risk classifications as of 2026. Startups are worse. The classification decision needs to live in your technical documentation, not in someone’s memory.

Annex IV Technical Documentation

Annex IV specifies what technical documentation a high-risk AI system must contain. This is a living document, not a one-time deliverable. It needs to be updated whenever the system changes materially.

The required sections map to these engineering artifacts:

1. General description of the AI system A clear statement of the system’s intended purpose, including the specific task, the deployment context, and the population of users it is designed to serve. This is not marketing copy. It is the specification an auditor will hold you to.

2. Detailed description of the elements of the AI system System architecture diagrams, data flow documentation, and the specific models or algorithms in use. If you use third-party foundation models, document which ones and under what API contracts.

3. Detailed description of the development process This is more involved than most teams expect. It includes:

• Training data sources, curation methodology, and known biases
• Data governance protocols (who has access, how data is cleaned, lineage tracking)
• Testing and validation methodology with quantified metrics
• Human oversight procedures during development

4. Detailed description of the monitoring, functioning, and control of the system How you detect performance degradation, what alerts fire, how you intervene, and what the rollback procedure is.

5. Description of the risk management system You need a documented risk register specific to this AI system, with assessments and mitigations for identified risks. This is not a generic security risk register. It is AI-specific: model drift, data poisoning, adversarial inputs, fairness failures, and so on.

6. Changes made throughout the lifecycle A changelog for the AI system itself, separate from your standard code changelog. Every significant model update, retraining run, or data source change needs a dated entry.

7. Standards applied If you follow any harmonized standards (ISO 42001, ISO 5338, NIST AI RMF), document them here.

A practical approach is to maintain the Annex IV file as a structured document in your repository, versioned with your code. A YAML or JSON schema works well for the structured sections. The free-text rationale sections are best kept in Markdown.

// Example schema for the Annex IV change log section
interface AISystemChangelogEntry {
  date: string; // ISO 8601
  version: string;
  changeType: "model-update" | "data-source-change" | "architecture-change" | "configuration-change";
  description: string;
  riskImpact: "none" | "low" | "medium" | "high";
  riskAssessmentUpdated: boolean;
  authorizedBy: string;
}

Keep this in your repository. Your CI pipeline should fail if the date and authorizedBy fields are empty on a new entry.

Logging and Traceability Architecture

Article 12 of the EU AI Act requires high-risk AI systems to automatically generate logs that enable traceability. For agent-based systems, this means every consequential decision the agent makes must be timestamped, attributable, and permanently retained for post-market monitoring.

“Permanently retained” is relative, but the minimum retention requirement is the lifetime of the AI system plus 10 years for certain categories. Plan for long retention from the start.

What to Log

At minimum, each agent decision event needs:

interface AIDecisionEvent {
  // Identity
  eventId: string;         // UUIDv7 (time-ordered for query efficiency)
  systemId: string;        // Which AI system made this decision
  systemVersion: string;   // Model version + prompt version + config hash

  // Context
  sessionId: string;       // Groups events in a single interaction
  userId?: string;         // Subject of the decision, if applicable
  requestId: string;       // Correlates to your API request logs

  // Decision
  decisionType: string;    // e.g. "cv-screening-score", "credit-risk-assessment"
  inputs: Record<string, unknown>; // The inputs the model received
  output: Record<string, unknown>; // The model's output
  confidence?: number;     // If the model produces one

  // Oversight
  humanOverrideAvailable: boolean;
  humanOverrideExercised?: boolean;
  humanOverrideBy?: string;
  humanOverrideAt?: string;

  // Immutability
  timestamp: string;       // ISO 8601 UTC
  checksum: string;        // SHA-256 of the event content, excluding this field
}

One constraint: the inputs field must not store raw PII beyond what is necessary for auditability. You need to balance traceability requirements against GDPR minimization requirements. In practice, store pseudonymized identifiers and a reference to where the full input data lives in your existing data store, subject to your data retention policy.

Append-Only Storage

Logs must not be alterable after the fact. Use an append-only storage pattern:

// Postgres example: enforce append-only via role permissions
// The service writing audit logs should use an INSERT-only role.
// No UPDATE, no DELETE on the audit log table.

const createAIAuditLogTable = `
  CREATE TABLE ai_decision_log (
    event_id        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    system_id       TEXT NOT NULL,
    system_version  TEXT NOT NULL,
    session_id      UUID NOT NULL,
    user_id         TEXT,
    request_id      UUID NOT NULL,
    decision_type   TEXT NOT NULL,
    inputs_ref      TEXT NOT NULL,  -- reference to input data, not raw PII
    output          JSONB NOT NULL,
    confidence      NUMERIC(5, 4),
    human_override_available  BOOLEAN NOT NULL DEFAULT FALSE,
    human_override_exercised  BOOLEAN,
    human_override_by         TEXT,
    human_override_at         TIMESTAMPTZ,
    ts              TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    checksum        TEXT NOT NULL,
    CONSTRAINT no_future_ts CHECK (ts <= NOW() + INTERVAL '30 seconds')
  );

  -- BRIN index works well for time-ordered append-only tables
  CREATE INDEX idx_ai_decision_log_ts ON ai_decision_log USING BRIN (ts);
  CREATE INDEX idx_ai_decision_log_session ON ai_decision_log (session_id);
  CREATE INDEX idx_ai_decision_log_user ON ai_decision_log (user_id);
`;

// Revoke UPDATE and DELETE from the application role
const lockdownPermissions = `
  REVOKE UPDATE, DELETE ON ai_decision_log FROM app_role;
`;

For high-volume systems, consider a write-ahead log fan-out pattern where events are written to Postgres for queryability and also streamed to cold storage (S3 with object lock enabled) for long-term immutable retention. Object lock prevents even privileged users from deleting records before the retention period expires.

Human Oversight Mechanisms

Article 14 requires high-risk AI systems to allow effective human oversight. This is not a UX checkbox. It is a product architecture requirement.

Specifically, the regulation requires that natural persons to whom oversight is assigned must be able to:

• Understand the system’s capabilities and limitations
• Monitor operation and detect anomalies
• Disregard, override, or interrupt the system
• Interpret the system’s output before acting on it

These translate to concrete engineering deliverables:

Override endpoints. Every consequential AI decision must have an API path or UI surface that allows an authorized human to override it. This override must be logged (see the humanOverrideExercised field above).

Circuit breakers. If the model’s confidence falls below a threshold, or if anomaly detection fires, the system should route to human review rather than proceeding automatically.

Explainability artifacts. For scoring or ranking outputs, you need to surface the features that drove the decision. This does not require full explainability (which is still an open research problem), but it requires enough context for an operator to exercise judgment.

interface AIDecisionWithOversight {
  decisionId: string;
  recommendation: unknown;
  confidence: number;

  // Minimal explainability for operator review
  topFactors: Array<{
    factor: string;
    direction: "increases" | "decreases";
    relativeWeight: number;
  }>;

  // Override surface
  overrideUrl: string;  // Where an authorized operator can review and override
  overrideDeadline?: string; // ISO 8601 — deadline before automatic action
  status: "pending-review" | "auto-processed" | "human-reviewed" | "overridden";
}

For agentic systems (multi-step agents that take actions, not just produce text), the “interrupt” requirement is especially important. You need defined checkpoints where a human can halt the agent before it proceeds. LangGraph’s interrupt() primitive is one implementation pattern. The specific tool matters less than the fact that the interruption points are defined, documented, and tested.

Accuracy, Robustness, and Cybersecurity

Article 15 requires high-risk systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. The Annex IV technical documentation must include the metrics you chose and the thresholds you set.

For accuracy, document the evaluation dataset, the metrics (precision, recall, F1, AUC-ROC, or whatever is appropriate for the task), and the minimum acceptable performance thresholds before deployment. These thresholds should be enforced in your CI pipeline.

For robustness, document how you handle:

• Distribution shift (model behavior when inputs differ from training data)
• Adversarial inputs (inputs crafted to fool the model)
• Partial failures (what happens if a dependency fails mid-decision)

For cybersecurity, standard controls apply with some AI-specific additions: model provenance verification (you can verify the model weights have not been tampered with), prompt injection protections for LLM-based systems, and access controls on training data pipelines.

Conformity Assessment

For most Annex III high-risk AI systems, conformity assessment is self-assessment. You apply the requirements, document compliance, sign a Declaration of Conformity, and affix the CE marking. A notified body is only required for certain categories (biometric identification, critical infrastructure safety components).

Self-assessment does not mean lightweight. It means you are the responsible party for demonstrating compliance. An auditor reviewing your CE marking can demand the complete Annex IV technical file.

The Declaration of Conformity must include:

• Identification of the AI system (name, type, version)
• Name and address of the provider
• Statement that the system conforms to the EU AI Act
• Reference to any harmonized standards applied
• Date and signature of an authorized person

After self-assessment, high-risk AI systems must be registered in the EU database before deployment. The EU AI Office operates this registry.

A Realistic Engineering Timeline for April Through August 2026

If you are starting now, you have roughly 14 weeks before August 2. Here is how to allocate them:

Week	Priority
1-2	Risk classification exercise. Document the outcome. Identify all AI-enabled features that may qualify as high-risk.
3-5	Annex IV documentation sprint. Assign owners to each section. Ship first draft of the technical file as a repo artifact.
4-6	Logging infrastructure. Implement the ai_decision_log table and event schema. Instrument all high-risk decision points.
6-8	Human oversight surfaces. Build override endpoints, circuit breaker logic, and interrupt points for agentic flows.
7-9	Accuracy and robustness documentation. Formalize evaluation datasets, run benchmarks, set thresholds, enforce in CI.
9-11	Gap review. Bring in a third party to review the technical file and flag gaps. Address findings.
11-13	Conformity assessment and Declaration of Conformity. Sign. CE mark. Register in EU database.
13-14	Buffer. Compliance documentation always takes longer than estimated.

This schedule assumes the system already exists and is in production. If you are also building the system during this period, the documentation sprint must run in parallel with development. Writing documentation after shipping is the failure mode.

Tradeoffs: Architecture Decisions with Compliance Implications

Decision	Compliance-favorable	Compliance-problematic
Logging storage	Postgres with append-only role + S3 Object Lock	Log aggregation tools that allow deletion (CloudWatch, Datadog without archival)
Model versioning	Explicit version strings in every log event	Implicit “latest” model aliases in production
Override surfaces	Dedicated review queue with time-bound SLA	Ad-hoc manual interventions without logging
Audit trail	Immutable event log with checksums	Mutable application logs
Documentation	Version-controlled in repo, updated at deploy time	Confluence pages updated manually on memory
Risk classification	Formal documented exercise, reviewed quarterly	Verbal agreement in Slack

The principle is straightforward: every compliance artifact needs to be a first-class engineering deliverable, treated with the same rigor as your schema migrations and API contracts.

The Scope Question for US-Based Companies

The EU AI Act applies when your AI system is placed on the EU market or when its output is used in the EU. If you have EU users or sell to EU enterprises, you are in scope regardless of where you are incorporated. The fact that US federal AI policy is currently fragmented does not reduce your EU obligations. Companies shipping to both markets face both regulatory environments simultaneously.

If you are building AI products and have EU users, assume you are in scope until a documented classification exercise tells you otherwise.

Closing

The EU AI Act compliance burden for high-risk systems is real and non-trivial. But it is also tractable: a team that starts the risk classification exercise today, treats Annex IV documentation as a first-class engineering artifact, builds append-only audit logging, and ships explicit human override surfaces will be well-positioned before the deadline.

The teams that will miss August 2 are the ones that have been treating compliance as a legal department problem. It is primarily an engineering problem, and engineering teams have the skills to solve it.