AI Compliance is a company’s ability to demonstrate that the Artificial Intelligence systems it uses meet applicable regulatory requirements, starting with the EU AI Act and the GDPR. Compliance depends less on the chosen model than on how the system integrating it into business processes is designed, controlled and documented.
Application Architecture for AI Compliance
When a company brings Generative AI into production, the first compliance question is almost always about the model: which one is most reliable, how often it refuses an unlawful instruction. It is an understandable question, but it points attention in the wrong direction. What determines compliance is the system built around the model.
European regulation assigns legal responsibility to the deployer, the party that integrates the model into a specific system, rather than to whoever trains and distributes it. As a result, governance and compliance have less to do with procurement and far more to do with architecture choices.
Providers and Deployers: How the AI Act Allocates Responsibilities
The EU AI Act is the first European regulatory framework governing the development and use of artificial intelligence systems through a risk-based approach. Adopted in 2024 and applied in successive phases, it classifies AI systems into four risk categories and assigns each one proportionate obligations. These range from bans on uses deemed incompatible with fundamental rights to simple information duties for limited-risk systems. We covered its strategic impact on companies in depth in our article AI Act and Operational Control: European Regulation as a Strategic Lever. Here we focus on one specific aspect: how the regulation divides responsibilities between those who develop models and those who use them.
GPAI Model Providers
GPAI (General Purpose AI) providers are the companies that train and distribute foundation models: OpenAI, Anthropic, Google, Meta, Mistral. These are general-purpose systems, trained on vast amounts of data and able to handle very different tasks. Precisely because they are general-purpose, nobody can govern them in advance for every context they will end up in.
The obligations the regulation places on these entities revolve around transparency and documentation. Providers must:
- produce and maintain technical documentation on the model;
- give deployers the information they need to understand its capabilities and limits;
- adopt a policy that complies with European copyright law;
- publish a summary of the content used for training.
Models with systemic risk carry additional risk assessment and management duties.
None of these obligations requires the model to refuse unlawful tasks, and there is a logic to that. A general-purpose model has no way of knowing whether an activity is lawful in the specific use case it will be placed in. Only whoever knows the application context can make that call.
The Deployer and Responsibility for the System
The deployer is the company that takes a model and builds it into a system with a precise purpose, such as a customer service agent or a document analysis tool in finance or law. In doing so, it takes on legal responsibility for how the system behaves in its operational context.
For high-risk systems, the obligations are explicit. The deployer must:
- assign human oversight to people with adequate skills and authority;
- monitor how the system operates and suspend it if risks emerge;
- keep generated logs for at least six months;
- inform workers when the system is involved in their activities.
The split follows a simple logic: the provider knows the model, the deployer knows the use case. If a model carries out a potentially unlawful instruction in a simulated scenario, that does not automatically make it non-compliant, because it lacks the context to assess the instruction. Building that context, along with the control mechanisms, is the deployer’s job. If a customer service agent produces problematic outputs, the company that configured it and put it into production is accountable, whatever the underlying model.
AI Act Deadlines
The AI Act applies in phases: some obligations are already operational, while others have been deferred.
For GPAI providers, obligations have applied since August 2025, and since August 2026 the European Commission can exercise its enforcement powers. Technical documentation therefore needs to be ready to show the authorities. Fines for violations reach up to 3% of global annual turnover or 15 million euros.
Since 2 August 2026, the transparency obligations of Article 50 also apply, regardless of risk class. People must be told when they are interacting with an AI system, if this is not obvious, and generated content must be identifiable.
For high-risk systems, the Digital Omnibus on AI has moved the deadline. Obligations for Annex III systems will apply from 2 December 2027. Annex III covers, among others, HR and recruitment, credit scoring, critical infrastructure and the administration of justice. For AI embedded in regulated products, the date is 2 August 2028.
Reading the deferral as a reason to wait would be a mistake. Documentable human oversight, auditable logging and conformity assessment before deployment all require architectural work, and that kind of work rarely gets done in the few weeks before a deadline.
The starting point is still mapping the AI systems in use: what they are, what context they operate in, how much autonomy they have and who actually oversees them. Without that picture, any regulatory risk assessment rests on partial information.
Guardrails, Logging and Access Control
A solid compliance posture is therefore first and foremost a stack engineering problem. Using model behavior as the first line of defense exposes the company to systemic legal risk. Models change with every update and react differently depending on context and prompts, while the company’s liability stays exactly where it was.
The safeguards that matter for compliance sit at the application and infrastructure level:
- inbound filters that inspect requests before they reach the model;
- outbound filters on generated responses;
- structured, auditable logs of every interaction;
- access controls that define who can use the system and with what autonomy;
- escalation to a human when the system faces high-uncertainty scenarios.
The Case of Agentic Architectures
With agentic systems, things get more delicate. These systems work autonomously across complex workflows, call external tools and correct their own course. When an agent acts on a CRM, an ERP or a database, a system prompt alone cannot govern it. It takes an infrastructure layer able to intercept, log and block anomalous behavior before it has irreversible effects.
Human supervision: a skill to be demonstrated
The human oversight required by the regulation is not about having someone read every output. For systems that operate autonomously, with agents as the clearest example, the most effective reference is the Human-on-the-Loop (HOTL) approach. In this model, the AI carries out the entire process autonomously, while a person acts as an external supervisor: they monitor what the system is doing and retain the power to step in or stop it if anomalies arise. The human-in-the-loop approach requires human approval at every step, whereas HOTL preserves the efficiency of automation without giving up control.
For this model to hold up, the power to intervene has to be concrete and demonstrable. Whoever supervises must be able to see what is happening, stop the process and reconstruct its decisions afterwards. That takes working logs, alerts and override mechanisms. A statement of principle in an internal policy will not survive an inspection on its own.
Three Compliance Approaches Compared
Enterprise environments mostly show three ways of handling compliance: relying on the model’s behavior, spreading controls across individual applications, or centralizing governance at the stack level. The table compares them.
| Approach | Where control resides | Stability over time | Traceability and audit | Human oversight | Deployer’s legal exposure |
| 1. Relying on the model | In the model’s behavior and refusal mechanisms. | Low; changes with every provider update. | Absent or left to the provider. | Cannot be demonstrated. | High; the liability remains, the safeguards are missing. |
| 2. Fragmented application controls | In each project’s code, with different logic for every team. | Medium; depends on how each application is maintained. | Inconsistent logs, hard to reconstruct during an inspection. | Partial and different from project to project. | Significant; hard to demonstrate compliance consistently. |
| 3. Centralized stack-level governance | In a single infrastructure layer applied to all flows. | High; policies stay valid even when the model changes. | Structured, centralized logs, ready for audit. | Documented, verifiable alerts, escalation and overrides. | Contained; compliance is designed, measurable and documented. |
Bitrock’s Approach
At Bitrock we see AI Compliance as a property of the architecture, something to design from the outset rather than reconstruct afterwards through documentation. It is the same approach to AI Governance we have discussed in our previous articles, and we apply it through an incremental path that does not stop teams from working.
We start by mapping the AI systems in use. For each one we reconstruct its operational context and degree of autonomy, and assign the risk class set out in the EU AI Act. On that basis we design the guardrails: inbound and outbound filters, sensitive-data masking rules and access policies tailored to each use case. The next step is traceability, with auditable logging of every interaction and retention periods aligned to regulatory requirements. Finally, we make human oversight verifiable by introducing alerts, escalation and override mechanisms consistent with a human-on-the-loop model.
On the technology side, we propose introducing the Radicalbit AI Gateway, part of the Fortitude Group product portfolio. It is a centralized layer that sits between business applications and LLM providers. In practice, the Gateway:
- Applies cross-cutting guardrails: inbound and outbound controls cover every project without changes to individual applications’ code.
- Produces a structured audit trail: every call is logged with metadata on model, latency, user and cost, so you can answer an inspection or reconstruct the system’s behavior at any time.
- Routes requests by compliance criteria: the most sensitive use cases can be isolated on on-premise models or geographically appropriate deployments, without touching application code.
- Decouples the company from providers: if a vendor changes policy, pricing or availability, switching to an alternative requires no architectural rewrites.
Conclusion
Choosing the “safest” model or trusting the refusal rates measured in benchmarks is not enough to comply with European AI regulation. That data helps explain how a model behaves, but conformity is assessed at a different level: the system the deployer builds around the model.
This change of perspective also has a practical upside. As long as compliance depends on the model, every provider update puts everything back on the table. Once it becomes a property of your own system, you can design, measure and demonstrate it with your own tools and on your own terms.
Contact the Bitrock team for a dedicated assessment. We start by mapping your AI systems to understand what it takes to make them compliant, traceable and ready for the upcoming AI Act deadlines.
FAQ
No. The AI Act gives GPAI providers transparency and documentation obligations on the model. Responsibility for how the system behaves in its operational context, however, stays with the deployer, the company that integrates the model and puts it into production. A strong benchmark score does not exempt you from building adequate guardrails, logging and human oversight.
The Digital Omnibus moved the deadline for Annex III systems to 2 December 2027, but transparency obligations are already in force. The work involved also takes time: system mapping, risk classification, logging and oversight are architectural interventions. Companies that start now reach the deadline with a settled posture instead of scrambling to adapt.
An AI Gateway such as Radicalbit’s sends all LLM traffic through a single control point. There, uniform guardrails can be applied, every interaction can be logged in an auditable way, and requests can be routed according to compliance criteria, for example to on-premise models for the most sensitive use cases. Bitrock handles its design and integration into the existing stack as part of a broader governance path.