EU AI Act and Generative AI FAQ
What the EU AI Act actually distinguishes — GPAI models versus high-risk systems — and the logging, transparency, and human-oversight practices that belong in the build, not in a slide.
The EU AI Act is a risk-tiered regulation: it bans a short list of practices, puts extra duties on general-purpose AI (GPAI) model providers, and applies the strictest system rules to high-risk uses such as hiring, credit, and certain safety components — not to every chatbot. Most enterprise assistants are transparency and logging problems, not automatic high-risk classification. This page is not legal advice.
What the Act actually covers
If you only need one split: GPAI rules target the model provider; high-risk rules target systems used in listed contexts. Most generative-AI deployments are neither banned nor automatically high-risk.
What is the EU AI Act?
It is the EU’s risk-tiered regulation for placing AI on the market and using it in the Union. It prohibits a short list of practices, imposes duties on GPAI model providers, requires transparency when people interact with AI, and applies the heaviest obligations to high-risk systems. It is not a ban on ChatGPT and not a single certification you buy. Dates and territorial scope are questions for counsel; this FAQ covers the engineering split teams actually get wrong.
Is ChatGPT banned in the EU?
No. Consumer ChatGPT, the API, and ChatGPT Enterprise remain available in the EU, subject to the Act, GDPR, and the provider’s own terms. A ban would be a prohibited-practice finding or a market restriction, not the default for a chatbot. What is restricted is using AI for listed banned purposes, and what is heavier is using it for high-risk decisions. Do not treat a vendor’s marketing page as a legal opinion.
What is a GPAI model under the Act?
A general-purpose AI model is one trained on broad data and usable for many downstream tasks — the foundation models you call via API or host yourself. Provider duties typically include technical documentation, a training-data summary, and a copyright policy; models classed as systemic-risk carry extra evaluation and incident duties. Your agent is usually a system built on a GPAI model, not the GPAI model itself. Fine-tuning can blur that line; get counsel on the facts.
What counts as a high-risk AI system?
High-risk is mostly a use-case list: employment, credit and essential services, education, biometrics, critical infrastructure, law enforcement, migration, justice, and certain product-safety components. Using GPT or Claude does not make a system high-risk. Using it to rank job applicants or to decide creditworthiness might. Classification is a legal and product decision. We will not stamp “not high-risk” on a demo.
Is our customer-support chatbot high-risk under the AI Act?
Usually no, if it answers policy, looks up orders, and escalates identity and billing disputes to a person. It becomes a different conversation if it decides eligibility for essential services, employment, or credit, or if it is a safety component of a regulated product. Limited-risk transparency still applies: users should know they are talking to an AI. Ask counsel to classify the live workflow, not the slide title.
What is the difference between a provider and a deployer?
In Act language, a provider places a system or GPAI model on the market under its name; a deployer uses an in-scope system in the course of its business. Most enterprises deploying an internal or customer-facing agent are deployers of a system and customers of a GPAI provider. If you substantially modify a model or put your brand on a system sold to others, provider duties can attach. That allocation is legal work. We document what we built so that work has a source.
When do the EU AI Act rules apply?
The regulation is already in force. Prohibited practices and GPAI provider duties have phased in ahead of the main high-risk system obligations, which continue to land through 2026 and 2027 depending on the annex. If you place or use systems in the Union, assume you are in scope and confirm dates with counsel — this page will not invent a countdown. Engineering work that helps regardless of the calendar: logs, human fallback, and a written description of what the system does.
What you actually build
The useful work is documentation, traces, scoped tools, and a human queue — practices that survive a legal review because they are how the system runs.
What logging does the Act expect from a production system?
For high-risk systems the Act expects automatic, time-stamped logs that support traceability. We treat that as the default for any production agent: inputs, retrieved passages, tool calls, model version, output, and the human decision if one happened. That is an engineering practice, not a claim that your file is Act-complete. Aggregated dashboards are not an audit trail. If you cannot reconstruct a single bad answer, you are not ready for a reviewer.
Do we need a human on every AI decision?
No. Oversight means a person can understand, override, and stop the system, and that high-stakes or low-confidence cases actually reach them. Forcing a click-through on every password-reset answer trains people to ignore the queue. We start write actions behind confirmation, route identity and irreversible changes to a human, and widen autonomy only when the eval suite holds. That is how you implement oversight without theatre.
Does ReinforcedX certify us against the EU AI Act?
No. We are not a notified body, we do not issue CE marks for AI systems, and we do not claim the systems we build are certified against the Act. Counsel and your risk function own classification and conformity. What we hand over is running software, traces, an eval suite, a runbook, and model-risk documentation mapped to your framework where you ask for it. That is evidence for a review, not a substitute for one.
What technical documentation should we keep for an agent?
A written intended purpose, the workflow boundary, data sources, tool allowlist, model and version, evaluation method, known failure modes, and the human-fallback path. High-risk annexes ask for more; even limited-risk systems benefit from the same packet because it is how you operate after handover. You own those artifacts. We do not keep the only copy in a slide deck on our side.
How does transparency work if users talk to an AI?
People must be able to tell they are interacting with an AI unless it is obvious from the context. Disclose in the first turn on chat and on voice; do not hide it in a footer. Deepfakes and synthetic media have separate labelling rules. Disclosure is not the same as consent under GDPR, and it is not a high-risk conformity assessment. We put the sentence in the prompt and the UI, then leave the legal wording to you.
Can we use US-hosted models for EU users?
Often yes, with a transfer story, a processor agreement, and the provider’s retention settings you can actually prove. The Act does not, by itself, forbid a US API. GDPR and your regulator might still prefer EU regions, zero-retention, or a self-hosted open-source model. We are model-agnostic and deploy in your VPC when that is the constraint. We will not invent a transfer mechanism that your DPO has not accepted.
What should we do in week one if we sell into the EU?
Write down the workflow, the user, the decision it is allowed to make, and the data it sees. Send that to counsel for a working classification: prohibited, high-risk, or not. In parallel we start traces, a human queue, and a golden set from real cases. Four weeks is discovery, environments, shadow-mode, handover — not a legal opinion. If the use case is high-risk, say so before we open write tools.
Running it without pretending you are certified
Production is perimeter, reconstructable decisions, and the honesty that a model update is an operational event, not a legal footnote.
Where should an EU-facing agent run?
In your cloud and region, against your identity provider, with secrets in your manager. That is our default for regulated work: VPC, on-prem, or your cluster — not a copy of customer data on ReinforcedX infrastructure. Region choice does not complete an Act assessment, but it is the difference between a reviewer seeing a system you control and a chatbot on a consumer plan. You pay the model provider directly; we add no token markup.
How do you handle audit trails for AI decisions?
Every run stores the inputs, retrieved context, tool calls, model version, output, and any human confirmation. Auditors get a reconstructable trail per decision, not a monthly accuracy percentage. Retention and access control on those logs follow your policy, including GDPR storage limitation. If a log cannot explain why the agent issued a refund, it is not an audit trail.
What happens when the model provider changes the model?
That is an operational change and, for documented systems, a configuration change you should be able to see. We pin versions where the API allows it, run the eval suite on live samples, and page on regressions. The Act’s robustness and logging duties, where they apply, assume you know which model produced a decision. Silent aliases are how that breaks. Routing and fallback stay in your account, at your rates.
Do open-source models escape the EU AI Act?
No. Open-source distribution has limited exemptions for some GPAI documentation duties; it does not exempt a high-risk system you deploy on Llama, Mistral, or a fine-tune. Self-hosting helps data residency and control. It does not delete classification, logging, or human-oversight design. We will recommend open-source when residency or cost is the constraint, not as a legal loophole.
How do you treat prohibited practices in a build?
We will not build social scoring, untargeted facial scraping, or the other listed prohibitions, and we will stop a scoping call if the workflow is one of them. That is a hard no, not a pricing conversation. Borderline biometric or emotion-inference requests go to your counsel before any environment is stood up. The four-week default assumes a lawful, bounded workflow with a success metric we can measure.
Who owns the compliance evidence after handover?
You do. Eval suites, golden sets, traces of the pilot, runbooks, and any model-risk write-up we produce are yours. Thirty days of on-call is included; a retainer after that is optional. There is no lock-in that requires us to keep the evidence. If your auditor cannot get the files without us, handover failed.
Classification traps and honest limits
The architecture travels. What does not travel is a blog post that classifies your hiring tool as a chatbot.
Are hiring or credit agents automatically high-risk?
They are in the high-risk conversation by default because employment and access to essential private services sit on the Annex III list. A résumé screener that ranks candidates is not “just RAG.” A support bot that explains a credit product is different from one that decides the limit. We will say if a requested workflow looks like a listed use, and we will not pretend a four-week chatbot package covers a conformity assessment.
How does the Act treat general-purpose models we fine-tune?
Fine-tuning can keep you a deployer of someone else’s GPAI model, or it can start to look like providing a new model or system, depending on how substantial the change is and how you place it on the market. That is fact-specific. We fine-tune inside your tenancy; you own the weights. We still will not tell you that a LoRA adapter “makes you the provider” or that it does not — counsel does, against the actual training run.
Does GDPR still apply alongside the AI Act?
Yes. The Act does not replace GDPR, ePrivacy, or sector rules. Lawful basis, purpose limitation, minimisation, and data-subject rights still apply to prompts, retrieval corpora, logs, and fine-tunes. A reconstructable audit log that keeps full customer utterances forever can satisfy one reviewer and fail another. We implement retention and redaction you specify; we do not pick your lawful basis.
Is this FAQ legal advice?
No. Nothing on this page classifies your system, sets your deadlines, or says you are compliant. It explains how practitioners split GPAI from high-risk, and which engineering controls — logs, oversight, documentation, perimeter — we actually build. For classification, territorial scope, and conformity, use qualified counsel. We will work from their written position rather than substituting ours.
How does a four-week implementation help Act readiness?
It gives you a bounded system with traces, evals, a human queue, and a runbook your engineers own — the materials a legal review actually needs. It does not complete high-risk conformity, and it does not make ReinforcedX your authorised representative. Discovery in week one is where we refuse out-of-scope or prohibited work. If the first workflow is high-risk, expect a longer governed pilot, not a stamp at day 28.
The EU AI Act separates prohibited practices, GPAI model duties, limited-risk transparency, and high-risk system obligations. A customer-support agent is not high-risk just because it uses a large language model. High-risk turns on the use case in Annex III and on product-safety roles, not on the brand of model. ReinforcedX is not certified against the Act and does not sell a compliance stamp. We build production systems with reconstructable logs, human fallback, scoped tools, and documentation your counsel can use. Work runs in your VPC. You own the artifacts. Four weeks is the standard implementation for one bounded workflow.
Keep reading
Ready to refine
your workflow?
Share your current process. We’ll help you identify what can be automated — and where efficiency can be reclaimed.