AWS Bedrock and the EU AI Act: Classify What You Build

Amazon Bedrock is a managed cloud service that lets you access third-party foundation models and build generative AI applications without managing the underlying infrastructure. From an EU AI Act perspective, Bedrock is an input — a capability layer. The Act's obligations attach to the AI system you build and deploy, not to the cloud service you rent.

That shifts the compliance question immediately. The right question is not "does Bedrock comply?" but "what have I built with it, for whom, and what decisions does it support?" Answer that, and the risk tier and your obligations follow directly from Article 6 and Annex III of Regulation (EU) 2024/1689.

Who You Are Under the Act

If you build an application on Bedrock, configure it for a purpose, and put it into service under your name — even as a SaaS product you sell to others — you are almost certainly a provider under Article 16. That carries the heaviest obligations: technical documentation (Article 11), a risk management system (Article 9), human oversight measures (Article 14), accuracy and robustness requirements (Article 15), conformity assessment (Article 43), an EU Declaration of Conformity (Article 47), and registration in the EU database (Article 49).

If you are integrating a third party's Bedrock-based application into your own operations — a vendor's HR tool, a procurement chatbot licensed from a SaaS company — you are a deployer under Article 26. Deployer obligations are lighter but real: verify the provider's compliance documentation, keep logs for at least six months (Article 26), inform workers' representatives before deploying the system in the workplace (Article 26), and ensure human oversight is maintained in practice.

Article 25 governs role shifts. If you take a third-party Bedrock application, put your name or trademark on it, substantially modify it, or change its intended purpose, you become the provider. A deployer that repurposes a general-purpose Bedrock assistant into a credit-screening tool for its own customers has crossed that line and inherits the full provider stack.

AWS's obligations under the Act are separate. As the provider of the foundation model service, AWS bears GPAI model obligations under Chapter V (Articles 51–55) for the underlying models it makes available through Bedrock. Those obligations — technical documentation to downstream users, copyright policy, training-data summaries — sit with the model providers offered through the service, not with you. You are a downstream provider of the system you build on top. Your GPAI obligation is primarily due-diligence: use a model whose provider has complied with Article 53.

Classify the System by Its Use

The Act sorts AI systems into four tiers. Tier three (limited risk) and tier four (minimal risk) carry modest or no mandatory obligations. The heavy regime — the full Articles 9–15, 17, 43, 47, 49, 72, 73 stack — applies to high-risk systems under Article 6.

Article 6 asks two questions. First: is your system a safety component of a product covered by EU product law listed in Annex I (medical devices, machinery, vehicles)? If yes, high-risk via Article 6(1) with a deadline of 2 August 2028. Second: does the system fall within one of the eight areas listed in Annex III? If yes — and it does not qualify for the Article 6(3) exemption — it is high-risk from 2 December 2027 (the date set by the Digital Omnibus agreed in May 2026, deferring the original August 2026 date).

The Annex III areas most relevant to Bedrock-based applications are:

Employment and worker management (Annex III, point 4) — systems that screen job applicants, rank candidates by predicted performance, evaluate employees, allocate tasks, or monitor work behaviour. A Bedrock-powered CV screener that ranks applicants for a hiring manager falls squarely here. So does a performance-management tool that uses model outputs to recommend promotions or flag underperformers.

Access to essential services (Annex III, point 5) — creditworthiness assessment and credit scoring (point 5(b), excluding fraud detection) and life/health insurance risk assessment and pricing (point 5(c)). A Bedrock application that generates a creditworthiness score to help a lender decide whether to approve a loan is high-risk. Fraud detection, robo-advisory, and AML screening do not fall in this category.

Education and vocational training (Annex III, point 3) — systems that determine access to educational institutions, evaluate learners, or monitor for exam cheating. A Bedrock-based tool that automatically scores student assignments and feeds those scores into admission decisions is high-risk.

Biometrics (Annex III, point 1) — systems for remote biometric identification, biometric categorisation, or emotion recognition where permitted. Note that emotion recognition in workplace and educational settings, real-time remote biometric identification in publicly accessible spaces for law enforcement, and biometric categorisation based on sensitive characteristics are prohibited under Article 5(1)(f), 5(1)(h), and 5(1)(g) respectively — not merely high-risk. Do not build these on Bedrock or any other service.

Law enforcement, migration, administration of justice (Annex III, points 6–8) — risk of offending/re-offending, asylum eligibility, evidence evaluation, influencing electoral processes. High thresholds and, in some cases, outright prohibitions under Article 5.

The Article 6(3) Filter

An Annex III system is not automatically high-risk. Article 6(3) provides a filter: if your system poses no significant risk of harm to health, safety, or fundamental rights — because it performs a narrow procedural task, improves the outcome of a previously completed human activity, detects patterns without replacing human assessment, or does preparatory work only — it may be exempt. One of these conditions is sufficient, not all four. But any system that profiles natural persons is always high-risk regardless of this filter. Providers relying on Article 6(3) must document the assessment and register the system under Article 49.

Limited-Risk Systems

Most Bedrock deployments land here. Customer service chatbots, content generation tools, coding assistants, internal knowledge-base assistants, marketing copy generators — none of these typically fall in Annex III, and none involves the kind of consequential individual decisions that define high risk.

For chatbot interfaces that interact directly with natural persons, Article 50 requires transparent disclosure that the person is interacting with an AI system (applies from 2 August 2026). For AI-generated synthetic media, Article 50 requires machine-readable marking. These are disclosure obligations, not the full high-risk stack. If your Bedrock application is a customer-facing chatbot, your primary EU AI Act obligation is the Article 50 transparency notice.

What High-Risk Providers Must Do

If your Bedrock system lands in Annex III and you are the provider, the obligations are substantial. Here is the core sequence:

Risk management system (Article 9). A continuous process throughout the system's lifecycle, not a one-off checklist. Identify foreseeable risks to health, safety, and fundamental rights for intended use and reasonably foreseeable misuse. Estimate likelihood and severity. Adopt measures to reduce residual risks. Test the system at appropriate development points — for a Bedrock recruitment tool, that means testing outputs across demographic groups for bias, testing failure modes, and documenting what happens when the model is prompted outside its intended scope.

Technical documentation (Article 11, Annex IV). Before you place the system on the market or put it into service, prepare a documentation pack covering the system's intended purpose, design and architecture, training and fine-tuning data, performance metrics, risk management records, and post-market monitoring plan. Bedrock-specific considerations include documenting which foundation model(s) you access, any fine-tuning you apply, and how you configure the system for its intended use. Technical documentation is retained for ten years under Article 18.

Data and data governance (Article 10). Training, validation, and testing data must be subject to appropriate data governance practices — relevance, representativeness, freedom from errors, completeness. If you fine-tune a Bedrock model on your own data, you own the Article 10 obligations for that fine-tuning dataset.

Human oversight (Article 14). The system must be designed so that natural persons can understand its outputs, intervene, override, or stop it. For a high-risk employment-screening tool, this means a human reviewer must be in the loop before any consequential decision is finalised — the system supports, it does not decide.

Conformity assessment (Article 43). Most Annex III systems (except biometrics, which generally require the Annex VII notified-body route) use the Annex VI internal self-assessment route. You assess your own compliance, prepare the technical documentation, and issue an EU Declaration of Conformity (Article 47). Register the system in the EU database (Article 49) before putting it into service.

Post-market monitoring (Article 72) and incident reporting (Article 73). Once deployed, providers must actively collect data on system performance and report serious incidents to the competent authority of the affected member state. Timelines under Article 73: 15 days from awareness as a general rule; 2 days for widespread infringement or critical-infrastructure disruption; 10 days where a person has died.

Deployer logging (Article 26). Deployers of high-risk systems must retain the automatically generated logs for at least six months.

Data Residency and Bedrock Configuration

Bedrock does not use your prompts or completions to train the underlying foundation models, which addresses a common concern about confidentiality and data leakage into future model versions. AWS provides standard data processing agreements and offers EU regions (including eu-central-1, Frankfurt) for data residency. For organisations subject to GDPR alongside the AI Act, deploying Bedrock workloads in EU regions — and executing an appropriate data processing agreement with AWS — reduces the data-flow complexity considerably. GDPR obligations (lawful basis, data subject rights, DPIA under GDPR Article 35 where high risk) run alongside the AI Act but are governed by separate rules and separate fines under GDPR Article 83.

How Confir Helps

Register the AI system you have built on Bedrock, classify it under Article 6 and Annex III using Confir's plain-English intake, and determine your role (provider or deployer). For high-risk systems, Confir's rule-based engine — deterministic and reproducible by design — runs the structured assessment across risk classification (AIRC), data and technical robustness (AITR), transparency and human oversight (AITO), and governance and post-market monitoring (AIGM). The output is a compliance package: Article 11 / Annex IV technical documentation, the Article 47 Declaration of Conformity, and an Article 27 Fundamental Rights Impact Assessment for qualifying deployers. For limited-risk chatbot deployments, the same intake routes you to the two Article 50 disclosure controls rather than the full high-risk stack. Pricing from €600 per year; no consultants, no implementation project.

Frequently Asked Questions

Does AWS bear the EU AI Act compliance responsibility for what I build on Bedrock?

No. AWS carries GPAI model obligations for the foundation models it makes available through Bedrock — principally the Article 53 baseline duties (technical documentation to downstream users, copyright policy, training-data summary) and, for systemic-risk models, the Article 55 obligations. Those rest with the model providers offered through the service. When you build an application on Bedrock, you become the provider of that application under Article 16. Conformity assessment, technical documentation, risk management, and registration are your obligations. AWS's compliance with its own layer does not flow down to cover yours.

Most of my Bedrock use is internal — do the obligations still apply?

Internal use is generally lower risk, and internal-only systems that stay genuinely internal (not sold or licensed to other organisations) attract different registration obligations. If the system is high-risk under Annex III and deployed internally in a professional context, the provider obligations still apply — you are both the provider and the deployer. The difference is that you are not placing the system "on the market," which simplifies some conformity steps but does not remove them. Internal chatbots used for drafting or research that do not make consequential individual decisions typically land in minimal risk, with no mandatory obligations.

If I fine-tune a foundation model on my own data through Bedrock, what changes?

Fine-tuning means you have substantially shaped the model's behaviour for your intended purpose. You carry Article 10 data governance obligations for your fine-tuning dataset — it must be relevant, representative, and free from errors to the extent possible. The fine-tuned model's outputs are your responsibility to test under Article 9. If the fine-tuned system crosses into an Annex III area because of how you have shaped it, the high-risk obligations apply from that moment, not only after you have served a certain number of users.

What does the Article 6(3) exemption mean in practice for Bedrock applications?

Article 6(3) lets you argue that a system in an Annex III area is not actually high-risk if it poses no significant risk to health, safety, or fundamental rights. One of four conditions suffices: narrow procedural task; improving a previously completed human activity; detecting patterns without replacing/influencing human assessment; or preparatory work only. A Bedrock assistant that drafts a first-pass summary of job applications for a human recruiter who then reads the originals themselves could qualify — the system does preparatory work, not the selection. Any system that profiles natural persons is excluded from the exemption. You must document the assessment and still register the system under Article 49.

When do the high-risk obligations apply for Bedrock-built systems?

Under the Digital Omnibus agreed in May 2026, stand-alone high-risk AI systems listed in Annex III must comply from 2 December 2027 (deferred from the original 2 August 2026). High-risk AI embedded in safety components of Annex I regulated products must comply from 2 August 2028. The Article 50 transparency requirements for limited-risk systems (chatbots, synthetic media) apply from 2 August 2026. Article 5 prohibitions have been in force since 2 February 2025; do not deploy prohibited use cases on any infrastructure.

Does Bedrock's multi-model catalogue create separate compliance exposures?

Each foundation model you access through Bedrock is governed by the model provider's GPAI obligations under Chapter V. Those are not your obligations — they are the model provider's. What matters for your compliance is the system you build using the model's outputs. If you switch from one foundation model to another within Bedrock for the same application, assess whether the switch constitutes a substantial modification under Article 3(23) — if it materially changes the system's outputs or risk profile, you may need to rerun the Article 9 risk assessment and update technical documentation.

What are the penalties if I get this wrong?

Non-compliance with high-risk provider obligations (Articles 9, 10, 11, 14, 15, 16, 43) and deployer obligations (Article 26) carries fines of up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher, under Article 99(4). For companies that are SMEs or start-ups, Article 99(6) caps the fine at the lower of the percentage or the fixed amount — a genuine proportionality protection. Violations of the Article 5 prohibitions carry the higher tier: €35,000,000 or 7%. The €7,500,000 or 1% tier applies to supplying incorrect or misleading information to competent authorities.

Related guides

• Annex III high-risk categories
• Article 6 high-risk classification
• risk classification decision tree
• 2026 implementation roadmap
• Article 8 compliance requirements
• Article 9 risk management system
• Article 43 conformity assessment process
• enterprise compliance obligations
• EU AI Act key requirements
• SaaS provider compliance requirements
• startup compliance timeline