What the EU AI Act requires, an honest map of where OGuardAI helps and where it does not, and what stays the customer's. Background, not legal advice.

Audience: security and compliance leads, Data Protection Officers, and engineering leaders putting sensitive data through AI in the EU

The EU AI Act (Regulation (EU) 2024/1689) is the question most regulated teams ask about before they adopt AI. This page states plainly what the Act requires, when it applies, and where OGuardAI fits. The honest headline: OGuardAI is one technical data-minimization control in the AI pipeline. It does not make a deployment AI Act compliant, it does not perform a conformity assessment, and it does not replace an AVV or DPA, a transfer impact assessment, a DPIA, a Fundamental Rights Impact Assessment, or legal counsel.

This page is background and a description of a technical control, not legal advice and not a certification. Whether a given deployment meets the EU AI Act, the GDPR, or any other obligation is a legal question for qualified counsel. OGuardAI is one control you operate inside an assessment you still own.

The framing is the same one used across these docs: own the runtime, not the model. Keep raw identifiers inside infrastructure you control, let the model work on tokens, and narrow what leaves your boundary. That is a real data-governance and security measure. It is a slice of the obligations, not the whole of them.

Timeline: when the Act applies

The Act entered into force on 1 August 2024 and applies on a staggered timeline.

Date	What applies
2 February 2025	Prohibited practices (Article 5) and AI-literacy duties (Article 4). Already in force, not deferred.
2 August 2025	General-purpose AI (GPAI) model provider obligations, governance rules, and national authority designation.
2 August 2026 (original)	Stand-alone Annex III high-risk obligations, Article 50 transparency, enforcement start. Now deferred for the high-risk items, see below.
2 August 2027 (original)	High-risk AI embedded in Annex I regulated products.

The Digital Omnibus deferral

The high-risk deadlines were pushed back. Council and Parliament reached a political agreement on 7 May 2026, the Parliament endorsed the package on 16 June 2026, and the Council gave its final green light on 29 June 2026. Under the deferral, stand-alone Annex III high-risk obligations move from 2 August 2026 to 2 December 2027, and embedded Annex I product AI moves to 2 August 2028.

Two caveats matter. First, the new dates bind only once the Omnibus is published in the EU Official Journal, entering into force on the third day after publication; publication was anticipated in July 2026, so verify the current status before relying on the December 2027 date. Until publication, the original 2 August 2026 date remains the formal law, so plan against it and treat the deferral as runway, not a cancellation. Second, the Article 4 AI-literacy and Article 5 prohibited-practice duties (in force since 2 February 2025) are not deferred, and the Article 50 transparency rules were not among the deferred high-risk items.

What the obligations are

The Act assigns duties by role. A short map of the ones a team adopting AI on sensitive data runs into:

GPAI model providers (Article 53). Maintain technical documentation of the model and its training, provide information to downstream providers, keep an EU-law-compliant copyright policy, and publish a public summary of training content. Systemic-risk models (presumed above 10^25 FLOPs of training compute) also notify the AI Office, run model evaluations and adversarial testing, mitigate systemic risk, and report serious incidents. Applied from 2 August 2025.
High-risk (Annex III) providers. Run a risk-management system, data governance (Article 10), technical documentation, automatic logging (Article 12), transparency and instructions for use, human-oversight-by-design, accuracy, robustness and cybersecurity, a quality management system, a conformity assessment, an EU declaration of conformity and CE marking, and registration in the EU database. Deferred to 2 December 2027 (pending publication).
High-risk (Annex III) deployers (Article 26). Use the system per instructions, ensure human oversight, monitor operation and report on risk, keep automatically generated logs for at least six months, inform affected persons, and for public bodies and certain private deployers run a Fundamental Rights Impact Assessment (Article 27). Deferred with the provider obligations.
Transparency (Article 50). Disclose AI interaction, mark AI-generated or manipulated content, and label emotion-recognition or biometric-categorisation use.
AI literacy (Article 4). Ensure staff and others operating AI have a sufficient level of AI literacy. In force since 2 February 2025.
Step Zero readiness. Before the high-risk date: build an inventory of every AI system, run a preliminary risk classification per system, map your role per system (provider, deployer, importer, distributor, noting that modifying or rebranding a third-party high-risk system can turn a deployer into a provider under Article 25), and stand up data-governance controls.

Article 10 in focus

Article 10 is the data-governance duty for high-risk systems, and it is where a data-minimization control is most relevant. Article 10(2) to (4) require training, validation, and testing data to be relevant, sufficiently representative, as error-free and complete as possible for the intended purpose, with documented origin, preparation, assumptions, bias examination and mitigation, and data-gap identification. This is dataset governance for whoever trains the model, and OGuardAI does not do it.

Article 10(5) is the exception that maps cleanly. It permits processing special categories of personal data (GDPR Article 9) to detect and correct bias, but only under safeguards: pseudonymisation and state-of-the-art security, strict documented access controls, no third-party access or transmission, deletion once bias is corrected or retention ends, and processing records justifying necessity. This is the Act's only explicit endorsement of pseudonymisation as a mandated technical measure, and it is where tokenization has a direct role.

Honest coverage map

OGuardAI is a request-time input and output control. It detects sensitive entities, replaces them with semantic {{type:id:cap}} tokens before text reaches an LLM, keeps raw values inside a self-hosted trust boundary (AES-256-GCM sealed sessions, EU-hostable), and restores per policy and channel. Mapped against the Act, that touches a few slices and leaves most of the obligations to the customer.

Obligation	Coverage	What OGuardAI does	What stays yours
GPAI provider baseline (Art. 53) and systemic-risk duties	Out of scope	Nothing. OGuardAI is not a GPAI model and trains no model; a customer running it is a downstream deployer.	The full GPAI obligation set, if you are a GPAI provider.
Member State authority designation and penalties	Out of scope	Nothing. This is a government obligation (in Germany, KI-MIG, BNetzA, BfDI).	Not applicable to a runtime.
Transparency (Art. 50)	Out of scope	Nothing. OGuardAI does not disclose AI interaction, watermark synthetic content, or govern emotion or biometric use.	Disclosure, content labelling, deepfake marking.
AI literacy (Art. 4)	Out of scope	Nothing. This is staff training.	The AI-literacy program.
Article 10(2) to (4) dataset governance	Partial support	Only as a pseudonymisation and minimisation measure. It does not assess dataset representativeness, statistical properties, bias, or data gaps.	Dataset lineage, representativeness, bias examination and mitigation, data-gap analysis.
Article 10(5) special-category pseudonymisation for bias correction	Direct control	Tokenization is pseudonymisation (10(5)(b)); caller_role and purpose-gated restore plus auth scopes are strict access controls (10(5)(c)); only tokens and safe metadata cross while raw stays in-runtime, so no third-party access (10(5)(d)); revocation plus session TTL is deletion after correction (10(5)(e)); the PII-free audit trail is processing records (10(5)(f)).	The necessity justification and the decision to process special-category data at all.
Automatic logging (Art. 12) and deployer logs at least 6 months (Art. 26)	Partial support	Per-operation audit events and an optional tamper-evident hash-chained file backend, with a PII-free NDJSON export, support the logging and record-keeping duty. The `--compliance` preset turns the durable, fail-closed backend on in one step.	Configuring the audit file path and retention, and the rest of the logging posture.
High-risk provider stack (risk mgmt, QMS, conformity assessment, CE marking, EU-DB registration, human oversight, accuracy)	Partial support	A security and data-minimization measure that supports the cybersecurity and protection-by-design expectation, plus the audit slice above.	Risk-management system, conformity assessment, CE marking, QMS, registration, human-oversight design, representativeness.
Deployer duties (Art. 26 monitoring, human oversight, inform affected persons; Art. 26(9) DPIA; Art. 27 FRIA)	Partial support	A named technical measure that lowers the DPIA and FRIA residual-risk analysis, plus an audit export as assessment evidence.	Authoring the DPIA and FRIA, human oversight, suspend-on-risk, and informing affected persons.
Step Zero readiness	Partial support	OGuardAI is one of the data-governance controls an org stands up: role-gated restore access control, per-operation audit and monitoring, trace_id incident reconstruction, policy-integrity signing.	The AI inventory, risk classification, and role mapping.

Where an AI system processes personal data, the GDPR applies alongside the Act and is not displaced. OGuardAI's core maps to three GDPR articles: tokenizing detected identifiers removes them from LLM context (Article 5(1)(c), data minimization); the trust boundary, sealed sessions, and fail-closed detection are data protection by design and by default (Article 25); AES-256-GCM sessions, key rotation, TLS, and a tamper-evident audit are security of processing (Article 32). This is one technical measure. It does not establish a lawful basis or set purpose limitation, which stay with the controller.

Two caveats that bound every claim

The same honesty rule applies here as everywhere in these docs:

Protection is scoped to detection. Only detected, non-whitelisted entities are protected. Person, company, and location detection requires the Python NER sidecar; in builtin-only mode those names are not tokenized and would reach the model. Set detection.required_for to fail closed when the sidecar is down. GLiNER items below the confidence threshold are not returned and cannot be protected.
Tokens are pseudonymous, not anonymous. The mapping, the safe metadata, and rare combinations can re-identify, so tokenization does not make a model anonymous and does not, by itself, place data outside the GDPR. It is a documented mitigating measure, not an escape from the rules.

The honest posture

OGuardAI is a control you operate, not a model, a contract, or a certification.
It contributes to the data-governance, security, logging, and pseudonymisation slices of the Act, most directly to Article 10(5) and the parallel GDPR Articles 5(1)(c), 25, and 32.
It does not make you AI Act compliant, perform a conformity assessment, or replace an AVV or DPA, a transfer impact assessment, a DPIA, a FRIA, or legal counsel.
Its strongest defensible claim is third-country-transfer minimization: when an entity is detected and masked, the provider never receives the raw value.

For the regulatory context and the section 203, CLOUD Act, and Schrems II detail, see Data Sovereignty and the Regulatory Timeline. For the control-by-control mapping, see Compliance Controls. For the binding technical detail, see Security Guarantees.

Sources

Regulation (EU) 2024/1689 (EU AI Act), Chapter III, Articles 4, 5, 9 to 17, 26, 27, 43, 47 to 50, 53, 99 to 101; Annex III.
European Commission AI Act Service Desk, implementation timeline.
Council of the EU press release, "Artificial Intelligence: Council and Parliament agree to simplify and streamline rules" (7 May 2026), and the subsequent Parliament endorsement (16 June 2026) and Council green light (29 June 2026) on the Digital Omnibus. Verify the Official Journal publication status.
European Commission, "Guidelines for providers of general-purpose AI models" and the GPAI Code of Practice.

EU AI Act Readiness