The technical controls the EU AI Act asks of your high-risk AI.

Provider or deployer?

The Act splits obligations by role, and most teams are both.

Provider if you build a high-risk system, which is the Art. 3(3) definition. You are also the provider if you put your name on someone else's system or substantially modify it, which is Art. 25(1). The duties are Art. 16: conformity assessment, CE marking, registration, technical documentation, plus the running controls.

Deployer if you use one under your own authority (Art. 26): human oversight, monitoring, retention of its logs.

We produce the technical controls and evidence both roles rely on, mapped below. Conformity assessment, CE marking and registration stay with you.

Is your system actually high-risk?

High-risk means either Article 6(1) product-safety law, or an Annex III use case under Art. 6(2): biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice. Risk assessment and pricing in life and health insurance sits at Annex III 5(c).

Art. 6(3) lets you treat an Annex III system as not high-risk where it poses no significant risk. Art. 6(4) is the duty to document that decision first.

Scoping is yours, usually with counsel. We handle the technical half once the system is in the high-risk tier.

Two things we do not reach: the Article 50 transparency duties, which apply at any tier, and the obligations on general-purpose model providers. We sit in front of a model, not at the training layer.

When the high-risk duties apply

Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on July 27, 2026. It pushed the Annex III obligations from August 2, 2026 to December 2, 2027, and the Annex I ones to August 2, 2028. The prohibited practices, the general-purpose AI duties and the Article 50 transparency rules kept their original dates. The extra sixteen months are for building the controls, and the systems in question are running now either way.

The high-risk controls, and what Swiftward provides

• Risk management (Art. 9): test a policy change in shadow and A/B against real traffic before it takes effect, and measure what it changed against your recorded history.
• Record-keeping (Art. 12): versioned policy with draft, candidate, frozen, and archived states; a decision record for every event, each naming the frozen version that was live.
• Human oversight (Art. 14): a human-in-the-loop queue with an optional timeout. You declare in advance what happens if nobody answers, and the decided case is recorded against it. Each deployment declares its own escalation steps.
• Transparency and robustness (Art. 13, 15): deterministic decisions you can explain, where the same input yields the same output.
• Explaining one decision to the person it hit (Art. 86): the decision record answers it, with the rule that decided, the frozen version it belonged to, and the signals it read. The duty itself: a deployer owes "any affected person subject to a decision which is taken by the deployer on the basis of the output from a high-risk AI system ... and which produces legal effects or similarly significantly affects that person" a clear and meaningful explanation of the system's role in it. Annex III point 2 is excluded.

Runtime redaction, and what Article 10 covers

Swiftward redacts personal data from a prompt before it reaches a model, which is a GDPR data-minimization control. Article 10 of the AI Act is about the training, validation, and test data your model learned from, its quality and representativeness, not about what you send a model at runtime. Swiftward does not train your model and does not address Article 10.

Feeds your technical documentation (Art. 11 / Annex IV)

Swiftward's versioned policy with diffs, its decision records, and its shadow and A/B results are supporting evidence for three things Annex IV asks a provider to document: your system's control logic, the changes made across its lifecycle, and how it is monitored. You assemble the file and keep it current.

Feeds your DPIA and FRIA

Swiftward gives your privacy and risk teams factual inputs for the impact assessments they owe: the controls in place, the decision and override records, the redaction configuration, and the logs of how the system behaved. A high-risk system that processes personal data usually needs a DPIA under GDPR Article 35; some deployers also owe a Fundamental Rights Impact Assessment under AI Act Article 27, which complements the DPIA rather than replacing it.

GDPR and data residency

Swiftward runs on your own infrastructure, in your EU region, with no data-plane sub-processors. Where you route a prompt to a model hosted in a third country, the redaction you configured runs before the prompt leaves your environment. You own and tune those rules; redaction reduces exposure, it does not eliminate it. For any personal data that still crosses a border, the GDPR Chapter V transfer rules still apply and remain yours. We sign a data processing agreement under Article 28.

What this is, and is not

No product is "AI Act compliant": the assessment is of your system and your organization, and no vendor can hold it for you. No tool makes an organization compliant. Swiftward enforces the technical controls the Act asks of high-risk systems and produces the evidence behind them. The conformity assessment, the CE mark, the DPIA, the FRIA, the documentation file: your teams do the demonstrating.