EU AI Legislation Is Live. Can You Answer These Five Questions?
The EU AI Act has been in force since August 2024. Prohibited practices expired in August 2025. High-risk AI obligations land in August 2026. If you're deploying AI systems in Europe — or deploying anything that processes data belonging to Europeans — the clock is already running.
Most organizations are still treating the AI Act as a compliance document to read and sign off on. They've assigned it to legal, flagged it as "in review," and moved on. This is the wrong approach.
The AI Act isn't primarily a legal text. It's a set of operational obligations. And the fastest way to understand whether you're actually compliant — not paperwork-compliant, but operationally compliant — is to answer five concrete questions about every AI system you run.
If you can't answer all five, you have work to do before August.
Why these five questions
The regulation runs to 180+ articles. But buried in the risk management provisions, transparency obligations, human oversight requirements, and liability framework is a consistent underlying structure: AI systems must be governable. Not just safe in the abstract — actively governable by identifiable people, with defined processes, auditable behavior, and a clear chain of accountability.
That structure collapses into five questions. They're not mine — they're the questions any regulator, auditor, or lawyer will ask first when something goes wrong. You should be able to answer them before something goes wrong.
Question 1: What data does it access, and what data can it change?
This sounds obvious. It rarely is.
In practice, most teams deploying AI systems in 2025-2026 have a reasonable answer for "what data does it read" (training data, input data, maybe a retrieval corpus) but a much fuzzier answer for "what data can it write, modify, or trigger changes to."
Agentic systems make this worse. An agent that sends emails, updates CRM records, calls APIs, or modifies configurations has write access to real systems. The AI Act's data governance provisions (Articles 10, 13) require you to document training data lineage, input data scope, and — crucially — what system state can be modified by the AI's outputs.
What compliant looks like: a maintained data map per AI deployment. Input sources (with access controls documented), output sinks (with write permissions documented), and a clear distinction between read and write paths. For high-risk systems, this needs to be auditable, not just asserted.
The gap most teams have: they've documented what goes in but not what happens downstream of the AI's outputs. If your AI recommends something and a human clicks approve, does the human's click count as the write? Legally: sometimes yes, sometimes no. You need to know which.
Question 2: Who supervises it?
The AI Act requires human oversight for high-risk AI systems (Article 14). Not "humans can review outputs if they want to." Defined human oversight — a named role with responsibility for monitoring the system's behavior, reviewing flagged decisions, and the authority to override or halt.
This question has two layers:
Operational supervision: who monitors the system day to day? Who gets the alert when the error rate spikes? Who reviews edge cases? In most organizations, this is an engineering on-call function. That's fine, but it has to be explicit. "The team monitors it" isn't sufficient — the team isn't a legal entity and has no authority.
Governance supervision: who has the authority to modify the system's parameters, retrain the model, or shut it down? For regulated industries this maps onto existing governance structures (risk committees, compliance officers). For startups it often doesn't map onto anyone, which is a problem.
What compliant looks like: for each AI system, a named individual or role with documented oversight responsibilities and the actual authority (access, tooling, process) to execute them. Not a RACI that points to "Engineering" — a person, or a clearly defined role, with real accountability.
The AI Office and national market surveillance authorities are the supervisory layer above your internal governance. They're not abstract. France's CNIL, Germany's BNetzA, Spain's AESIA — these bodies are actively building enforcement capacity.
Question 3: Where does it store information?
GDPR and the AI Act overlap significantly on this. The AI Act's transparency obligations and data governance requirements presuppose that you can answer where model inputs, outputs, and intermediate states are persisted.
This gets complicated quickly for systems using third-party model providers, retrieval-augmented generation with external vector databases, fine-tuned models hosted by cloud providers, or multi-agent architectures where one agent hands off context to another.
What compliant looks like: documented data residency for every persistent store the AI system touches. This includes: input data, output data, conversation history or session state if retained, embeddings in a vector database, fine-tune training data, audit logs.
For high-risk AI (employment decisions, credit scoring, access to services, law enforcement), data must be retained in a way that enables post-hoc auditing. You need to be able to reconstruct what the system did with what data, for a specific decision, on a specific date. If you're relying on a provider that doesn't offer that level of logging, you have a compliance gap.
The cloud provider question: if you're using a US-based LLM provider (OpenAI, Anthropic, Google) with no EU data residency, the question of where data goes in transit is live. Most enterprise agreements include data processing addenda that attempt to address this. Most engineering teams have never read them.
Question 4: Who is responsible if it makes a mistake?
The AI Act's liability framework, combined with the pending AI Liability Directive, is designed to answer this at a macro level. But the practical question is internal: before the regulator asks, does your organization know?
There are three liability roles in the AI Act's structure:
Provider: the organization that develops or places an AI system on the market. If you fine-tune a model, build a product on top of a model, or develop an AI tool for others to use, you're likely a provider.
Deployer: the organization that puts an AI system into use in a specific context. If you're using an AI vendor's product within your business operations, you're a deployer.
Operator: in some contexts, a hybrid — an organization that both configures a model and deploys it.
Most organizations are both providers (of their own AI tools) and deployers (of third-party AI). The obligation split between them matters: providers are responsible for the system's fundamental design safety; deployers are responsible for appropriate deployment context and oversight.
What compliant looks like: documented allocation of obligations between your organization and your AI vendors. Your enterprise agreements should specify who is the provider of record for each system. If a vendor says "we're just infrastructure," and you're building an AI product on top, you're the provider — with provider-level obligations.
The real gap: most organizations haven't had the liability conversation with their AI vendors yet. The contract was signed, the API key is in production, and nobody has formally allocated who answers to the regulator.
Question 5: How do you turn it off if it starts behaving badly?
This is the question most teams find hardest to answer, not because the mechanism doesn't exist, but because it's never been explicitly designed.
Article 9 (risk management) and Article 14 (human oversight) together require that high-risk AI systems have defined procedures for halting operation when safety or accuracy thresholds are breached. This isn't "you can turn off the server." It means:
- Detection: how do you know it's misbehaving? What metric, alert, or review process surfaces the problem?
- Classification: what constitutes "behaving badly" for this specific system? Model drift? Demographic disparity in outputs? Error rate exceeding threshold? Adversarial prompt injection in production?
- Authorization: who has the authority to decide to halt?
- Execution: what does halting mean? Kill the API? Roll back to a previous version? Disable a specific feature? Switch to a manual fallback? The answer is different for every system.
- Communication: who gets notified when a halt happens? Users? The regulator? (For high-risk systems in certain categories, incident reporting to the AI Office is mandatory.)
What compliant looks like: a runbook — not a theoretical kill-switch, but a documented procedure tested at least once, with named owners at each step.
Why most teams fail here: the system got deployed incrementally. There was never a "what's the shutdown plan" design session. The kill-switch exists in principle (turn off the server) but the detection and authorization layers don't exist, so in practice the system would continue misbehaving until someone noticed and escalated through informal channels.
The pattern behind the five questions
Read them together: data access/modification, supervision, storage, liability, shutdown. They're not five independent requirements. They're five facets of a single question: is this AI system governable?
Governance requires that someone can observe the system (questions 1, 3), that someone has authority over it (questions 2, 4), and that authority can be exercised in practice (question 5). If any of the five is missing, the governance loop is broken.
The EU AI Act is operationalizing this in law because the voluntary approach didn't work. Principles without enforcement don't change behavior. The Act is enforcement.
What I'd do this quarter
If you're deploying AI systems in Europe, or deploying anything touching European data, the practical sequence:
-
Inventory your AI deployments. Not just the AI products you sell — all AI you run internally. HR screening tools, customer service bots, fraud detection, recommendation engines. The Act applies to systems you use, not just systems you build.
-
For each system, answer all five questions. Write them down. "We haven't decided yet" is an answer — it means you have a gap.
-
For anything in the high-risk categories (Annex III of the Act: biometrics, critical infrastructure, employment, education, law enforcement, border control, administration of justice, essential services) — prioritize. August 2026 is the hard deadline, and implementing compliant human oversight, audit logging, and risk management takes time.
-
Get your vendor contracts in order. Who is the provider of record? What data processing obligations has the vendor assumed? What audit capabilities do they provide?
-
Build the runbook for question 5. Of all five, this is the most operational and the least likely to exist. Build it before you need it.
The AI Act isn't perfect regulation. Some definitions are contested, some thresholds are arbitrary, and the implementation guidance is still emerging from the AI Office. But the five questions are sound engineering regardless of regulation — they're what responsible deployment of consequential systems has always required. The Act is just making it mandatory.
Deploying AI systems into production in Europe and need engineering capacity that already operates with these governance controls baked in? Talk to us — our nearshore squads are building AI systems with audit logging, human-oversight hooks, and compliance runbooks as standard practice, not afterthoughts.
