The technical controls the EU AI Act asks of your high-risk AI.
The Act does not ask you to mean well. It asks you to manage risk, keep records, keep a human in the loop, and prove it. Swiftward gives you those controls and the evidence to show an auditor, on infrastructure that keeps personal data in the EU. What you owe depends on whether you are the provider or the deployer, so we start there.
Provider or deployer?
The Act splits obligations by role, and most teams are both. If you build or substantially modify a high-risk system and put your name on it, you are the provider (Art. 16): you owe the conformity assessment, CE marking, registration, and the technical documentation, on top of the running controls. If you use one under your own authority, you are the deployer (Art. 26): you owe human oversight, monitoring of its operation, and retention of its logs. Swiftward produces the technical controls and the evidence both roles lean on, mapped in the next section. What it does not do is the conformity assessment, CE marking, or registration; those are organizational acts that stay with you.
Is your system actually high-risk?
These obligations attach to high-risk systems: those covered by Article 6(1) product-safety law, or one of the Annex III use cases (Art. 6(2): biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice). Article 6(3) lets you treat an Annex III system as not high-risk where it poses no significant risk, but you have to document that call. Scoping your system is yours to make, usually with counsel; Swiftward does not classify it for you. Once it is in the high-risk tier, the technical half is what Swiftward handles. Two things it does not reach: the Article 50 transparency duties that apply at any risk tier (telling people they are dealing with AI, marking synthetic content), and the separate obligations on general-purpose model providers. Swiftward sits at the deployment layer in front of a model, not at the training layer.
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; replay history to measure its effect.
- Record-keeping (Art. 12): versioned policy with draft, candidate, frozen, and archived states; full decision traces; replay on the exact version that was live.
- Human oversight (Art. 14): a human-in-the-loop queue with escalation and timeouts, whose decisions re-enter the same audited pipeline.
- Transparency and robustness (Art. 13, 15): deterministic, replayable decisions you can explain, evaluated on event time so the same input yields the same output.
Runtime redaction is a GDPR control, not Article 10
Swiftward redacts personal data from a prompt before it reaches a model, which is a GDPR data-minimisation control. It is worth being exact, because the mapping is easy to fudge: 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 traces, its shadow and A/B results, and its replay records are supporting evidence for your system's control logic, the changes made across its lifecycle, and how it is monitored, which is much of what Annex IV asks a provider to document. You assemble the file and keep it current; Swiftward supplies the verifiable record several of its sections rest on.
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 actually behaved. A high-risk system that processes personal data usually needs a DPIA under GDPR Article 35; a narrower set of deployers also owes a Fundamental Rights Impact Assessment under AI Act Article 27, which complements the DPIA rather than replacing it. Swiftward gives your teams material to write against instead of assumptions.
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 residual personal data that 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 tool makes an organization compliant; compliance is organizational. Swiftward enforces the technical controls the Act asks of high-risk systems and produces the evidence behind them, so your teams can demonstrate them to an auditor. The conformity assessment, the CE mark, the DPIA, the FRIA, the documentation file: Swiftward feeds the evidence, your teams do the demonstrating.