The EU AI Act and your system card
What the AI Act asks of an organisation that uses an AI system rather than builds one, what the system card records, and why the inference region says unverified.
Most writing about the EU AI Act is addressed to the people who build AI systems. You almost certainly do not build one. You bought a security platform that has a model inside it, and somebody — an auditor, an insurer, a customer's procurement team, possibly your own board — has asked what that means for your obligations.
This article covers what the Act asks of an organisation in your position, what the platform hands you to answer it with, and one thing the card reports as unverified that a less honest vendor would report as EU-only. That last part is the reason this article exists.
What the Act asks of an organisation that uses an AI system
The Act splits its duties between the party that places a system on the market and the party that uses it under its own authority. Conformity assessment and technical documentation sit with the first. Your side is lighter, and it is mostly about competence, oversight and record-keeping rather than paperwork you would need an engineer to write.
- Know what you have switched on. You are expected to use the system in line with its instructions, which presupposes somebody has read them. Here that means knowing which autonomy tier you run and what it permits — see What Sentinel-Q is allowed to do.
- Assign human oversight to somebody who can exercise it. A named person who can understand the output, disagree with it and stop it. A person who cannot in practice override the system is not oversight, whatever the org chart says.
- Keep the logs, and maintain your own AI literacy. Records relevant to the system's operation are expected to be retained; how long they live is governed by your retention setting. The literacy duty is the one most often ignored and the cheapest to meet.
None of that requires you to re-derive facts about the model. It requires you to be able to produce them, which is what the system card is for.
What the system card is, and where to get it
The card is a machine-generated description of the AI component of this platform: what it is called, what class we have assigned it, what it can do, what human control sits over it, and how its data is handled. It is generated per request from the configuration the running process is using, rather than maintained by hand.
GET /api/v1/organizations/{orgID}/ai/system-card
permission: compliance:frameworks (read)That derivation is the design intention, and the reason for it is recorded in the code rather than in a marketing claim. An earlier version of this endpoint asserted two things in fixed text that were not true of the running system, and — this is the part that matters — there was no mechanism by which anybody would have found out. A hand-written card drifts silently. A derived one cannot.
| Field | What it holds |
|---|---|
system_name | Qorionix Security Copilot. The AI component, not the whole platform. |
risk_class | limited. An assertion by us, not a determination by any authority. |
risk_class_status | The literal string self-assessed; pending legal review against Annex III. |
capabilities | Summarise SIEM alerts and XDR incidents; propose response action plans with human approval gates; suggest configuration changes subject to operator review. |
oversight | Human in the loop, the audit trail, blast-radius gating, autonomy tiers. |
data_handling | Training, retention, and the residency block — inference geography, its provenance, and the disclosure that follows. |
last_reviewed_at | When the card was generated, in UTC. Regenerated on every request, so it is not a review date in the human sense — do not present it as one. |
Why the risk class is flagged rather than simply stated
The card reports limited and immediately qualifies it. The reasoning is short and we would rather publish it than have a reviewer find it: Annex III, which enumerates high-risk uses, contains no cybersecurity carve-out, and a system that recommends and executes security actions plausibly falls within it. So limited is a position we hold and must justify, and the card carries that status in the same object rather than in a footnote. If your adviser reaches a different conclusion, the consequence is not that the platform stops working — it is that the deployer obligations above get heavier, including in some cases an impact assessment on fundamental rights, for which the platform ships a template.
Human oversight and logging, as the card states them
Three of the oversight statements are structural properties rather than promises about behaviour, and they hold at every autonomy tier:
- Any action step marked
blast_radius=highrequires human approval before execution. The gate is in the server, not in the prompt. - Grant-class privileged actions are not exposed to the model at all. A capability absent from the toolset cannot be reached by a cleverly worded instruction. Granting privileged access is never automated, at any tier and any confidence.
- A verdict whose citations do not verify cannot drive an automated action. Ungrounded means unauthorised.
The logging statement is deliberately narrower than the sentence a vendor would prefer. The card says conversational calls persist the prompt, the reasoning and the response to ai_audit_trail, and that agentic triage decisions, their evidence citations and their verification outcomes persist to xdr_sentinelq_decisions.
The inference region, and the claim we refuse to round up
Everything Sentinel-Q sends to a model is security telemetry: alert text, process command lines, hostnames, usernames, sign-in addresses. That is personal data and the most operationally sensitive material your organisation has. Where it is processed is a real question, and a different one from where your data is stored — see Where your data lives.
The card does not report the region of the model resource, because a resource's region is not where inference happens. It reports a derived inference geography together with how much that derivation is worth:
- verified
- Observed from the model platform itself. The strongest provenance, and not currently reachable: the platform we use returns no inference geography to read.
- derived
- Mechanically derived from the declared deployment type and its region using documented Azure SKU residency rules. The mapping lives in code, not in an operator's belief, which is why it counts.
- asserted
- An operator declared a geography and nothing corroborates it. A declaration is not a measurement, so the card reports
unverified. - undeclared
- Nothing was declared and nothing could be derived.
eu_data_residency_holds is true only when the geography is inside the EU and its provenance is verified or derived and no non-EU override is recorded. In every other case inference_region takes the literal string unverified, and the card explains which case you are in.
Derived at request time from the model endpoint's deployment type and region using the documented Azure SKU residency rules, not from the endpoint hostname. A resource's region is not its inference geography: a resource in an EU region served by a Global Standard deployment runs inference wherever the platform has capacity.
The default disclosure, when nothing establishes EU inference to a checkable standard, is what you should quote:
EU residency for AI inference is not established to a verifiable standard for this deployment. An operator assertion alone is reported as unverified.
Where a deployment has explicitly recorded a decision to run inference outside the EU, the card sets residency_override_recorded and says in as many words that alert text, command lines, hostnames, usernames and sign-in addresses go to an endpoint whose inference is not confined to the EU. One field exists to be ignored: an operator-supplied region appears as configured_endpoint_region, marked informational only, and cannot make eu_data_residency_holds true.
The other AI Act surfaces, and what is not built
GET /api/v1/organizations/{orgID}/compliance/aiact/systems
GET /api/v1/organizations/{orgID}/compliance/aiact/fria/template
GET /api/v1/compliance/aiact/transparency?locale=enThe fundamental rights impact assessment template is version fria-v1 and carries the headings the Act expects: intended purpose, affected groups, the rights engaged, mitigations, a residual risk rating, the reviewer and the date. It is a template.
What to read next
- Where your data lives — home-region binding, storage versus inference, and what a DPIA needs from us.
- The evidence bundle: what an auditor gets — the artefact the AI Act section is exported inside.
- Our claims guardrail — the never-say list this article is written against.