> ## Documentation Index
> Fetch the complete documentation index at: https://docs.guardway.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# EU AI Act Mapping
> How Guardway capabilities support the obligations the EU AI Act places on providers and deployers of AI systems — article by article, gaps included.
**Read this first.** The EU AI Act places obligations on *you* — the provider
or deployer of an AI system — not on your tooling. No product makes you
compliant, and Guardway does not claim to. This page maps Guardway
capabilities to the articles they **support**, so your compliance team can
cite concrete technical controls as evidence inside your own compliance
programme. Where Guardway does not help, this page says so.
## How to read this page
Each section names an article, states what it requires in one line, lists the
Guardway capabilities that produce supporting evidence, and — where relevant —
states the gap. Capabilities link to their own documentation; nothing below is
aspirational.
## Article 9 — Risk management system
*Requires an iterative, lifecycle-long process of identifying, estimating and
mitigating the risks of a high-risk AI system.*
| Capability | What it evidences |
| --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Red-team scanning | Recurring adversarial testing of your LLM endpoints; run severity is computed from the bypass *rate* (gateway v0.4.41+), so results are comparable across runs |
| [Agent discovery](/platform/agents) | Inventory of AI agents across your cloud accounts, each evaluated against the OWASP Agentic Security (ASI) Top 10 — including which categories were assessed and which have stated limitations, so absence of findings is never silently mistaken for absence of risk |
| [Behavioral drift detection](/platform/configuration/security) (beta) | Per-key behavioral fingerprints that raise incidents when a credential starts behaving like someone else is holding it |
| [Guardrail policies](/platform/configuration/security#guardrails) | Risk *treatment*: monitor or block, per policy, per application |
**Gap, stated plainly:** Guardway evidences *operational* risk management of
deployed systems. Article 9 also covers design-time risk analysis of the model
itself (training choices, foreseeable misuse analysis), which is outside what
a gateway can observe.
## Article 10 — Data and data governance
*Requires appropriate data-governance practices, in particular for personal
data reaching the system.*
| Capability | What it evidences |
| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [PII detection and masking](/platform/configuration/security) | Sensitive spans (emails, cards, identifiers, secrets) detected in prompts — and in responses for policies scoped to output; masking rewrites the prompt before it reaches the provider and the response before it reaches the caller |
| Redaction-first event storage | The stored preview on a guardrail event is masked by the gateway's built-in content filter before it is written — every span the gateway can recognise is scrubbed, even for monitor-mode policies (model-detected entities outside those patterns may still appear). Full replay capture is **off by default** and requires an explicit opt-in |
| [The data boundary](/resources/privacy-and-security#the-data-boundary) | From gateway v0.4.41, prompts and completions are **not sent to Guardway Cloud by default** — they stay in your gateway's local store, under your retention control |
| [SIEM export](/platform/settings/integrations) | Bodies are excluded from forwarded events unless the destination explicitly enables `include_payloads` |
**Gap, stated plainly:** Article 10 is primarily about *training, validation
and testing data*. Guardway governs runtime traffic; it has no visibility into
how a model was trained. Cite it for the personal-data-in-operation half of
the article, not the dataset-governance half.
## Article 12 — Record-keeping
*Requires automatic recording of events (logs) over the system's lifetime.*
| Capability | What it evidences |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Request logs](/platform/logs) | Proxied requests recorded with identifiers, model, token counts, cost, latency and outcome (OpenAI pass-through endpoints such as Assistants record identifiers, status and latency only; logging is asynchronous) |
| Administrative audit log | Configuration changes, key rotations, role changes and gateway registrations, recorded centrally ([Settings → Audit Log](/platform/settings/audit-log)) |
| Guardrail events | Every detection with severity, action taken and a redacted preview |
| [SIEM export](/platform/settings/integrations) | Splunk HEC, syslog CEF/LEEF and NDJSON webhook delivery into your existing log-retention regime |
Retention is split by design: gateway-local logs live in storage you own and
manage (apply your own database or volume lifecycle — the gateway does not
enforce a retention schedule); cloud-side raw request events age out on a
rolling 30-day window, with only aggregates retained beyond it.
## Article 14 — Human oversight
*Requires that systems can be effectively overseen by natural persons.*
| Capability | What it evidences |
| --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Monitor-first guardrails | Prompt-injection and toxicity policies run in monitor mode by default, so humans review findings before switching on enforcement; PII rules default to masking and secret/credential detection defaults to block |
| [Alerting and webhooks](/platform/settings/notifications) | Detections, budget breaches and incidents pushed to the channels your operators watch |
| Key revocation and policy blocks | An operator can cut off an application, key, or user; revocation reaches cloud-connected gateways within the config-sync interval (typically under a minute) — the practical "stop" control |
**Gap, stated plainly:** Guardway has no human-in-the-loop approval workflow
(a pending request waiting for a person to approve it). Oversight here means
observe, alert, and revoke — not pre-approval.
## Article 15 — Accuracy, robustness and cybersecurity
*Requires resilience against errors, faults, and attempts to exploit the
system.*
| Capability | What it evidences |
| -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Prompt-injection detection](/platform/configuration/security) | Injection and jailbreak patterns detected at the gateway, before the model |
| Configurable failure mode | Guardrail evaluation can fail **closed** — if the inspection service is unavailable, traffic is refused rather than waved through |
| [Rate limits, quotas and budgets](/platform/configuration/api-keys) | Resource-exhaustion resistance per key, per team, per application and per organization |
| [Routing and failover](/platform/configuration/routing) | Continuous provider health checks exclude unhealthy providers from routing, so traffic shifts to healthy ones per your strategy; routing rules also support fallback providers on budget/token limits |
| [Container hardening](/resources/privacy-and-security#container-hardening) | Non-root runtime by default; compatible with a read-only root filesystem, dropped capabilities and seccomp when set in your deployment |
| MCP server health checks | Registered HTTP/SSE tool servers probed on a timer (gateway v0.4.41+, default every 5 minutes; stdio servers opt in); an unreachable server is surfaced instead of silently trusted |
## Article 50 — Transparency
*Requires that people are informed when they interact with an AI system.*
Guardway's agent discovery flags agents whose system instructions direct them
to **conceal their AI identity or impersonate a human** — the configuration
shape most likely to put a deployer in breach of Article 50. The finding names
the pattern matched, never the instruction text itself.
## Machine-readable mappings
Agent findings carry [OWASP ASI Top 10](https://owasp.org/) category tags
(`ASI01`–`ASI10`) in both the API and the dashboard. An explicit per-category
coverage statement (which categories are assessed, with what limitations) is
returned by the discovery summary API; surfacing it in the dashboard is
planned. Mappings to OWASP LLM Top 10, MITRE ATLAS and ISO/EU control
identifiers as machine-readable tags are on the roadmap and are **not shipped
today**.
## Residency, stated plainly
The Guardway control plane runs in a single US region today. Prompts and
completions stay on your gateway by default (v0.4.41+), but configuration,
administrative audit logs and aggregate telemetry are processed in the US. If
your reading of your obligations requires EU-resident *metadata*, raise it
with us before you buy — do not assume.
See also the [ISO/IEC 42001 mapping](/resources/compliance/iso-42001) and
[Privacy and Security](/resources/privacy-and-security) for the underlying
data boundary.