Blog
EU AI Act: Achieve compliance and transparency with AWS
AWS Consultant
Monday, 8:12 a.m. The Slack channel “go-live” is exploding. The HR bot is scheduled to appear on the homepage today. “Are we still allowed to do that? The EU AI Act is now in effect,” writes the Legal department. Five minutes later, the Production team reports in: “Our vision model is suddenly producing more false positives. Do we need to report an incident?” Then marketing asks whether the AI-generated images in the fall campaign need to be labeled.
We see scenes like this every week. The point is that the EU AI Act does not seek to stifle innovation. It wants us to be able to verify what we are doing and to set limits where fundamental rights are concerned. This is not red tape, but an invitation to treat AI like any other product in regular operation: With a clear purpose, data under control, managed risks, and measurable quality.
The good news is that this can be done. However, this is only possible if teams understand transparency as a UX feature – that is, honestly communicate that an AI is responding and cite the relevant sources – build an evidence chain from the dataset to the decision, and monitor not only whether the system is “running” but also its quality, drift, and security. This is exactly what the AI Act is useful for: It makes AI predictable for products, legal matters, and operations.
What the law really wants (without legal jargon)
The EU is taking a risk-based approach. Not every AI poses the same level of risk: a website chatbot is a bit different than a credit decision. This is why the obligations vary depending on the area of application and range from clear prohibitions (e.g., social scoring) to transparency obligations for a “limited risk” to extensive requirements for high-risk systems.
What is off limits? Practices that are a structural violation of fundamental rights, such as “untargeted” mass scraping of faces to create databases, biometric categorization of sensitive characteristics, and social scoring by authorities. Systems that recognize emotions are also very restricted in schools and at the workplace. The AI Act thus draws a red line where the imbalance of power is especially pronounced.
What does “low/limited risk” mean? Many everyday assistants. Here is where the AI Act demands transparency above all: Users must be able to recognize that they are interacting with AI, and synthetic media should be clearly labeled as such. In addition, a simple escalation path must be in place to transfer customers to a human agent in case of problems or uncertainties.
Where does high risk begin? In domains where AI plays a crucial role in determining access to opportunities, rights, or security, such as in education and examinations, employment and recruiting, credit and insurance, critical infrastructures, or law and administration. For these systems, the AI Act requires an evidence chain throughout the entire life cycle: Documented risk management, data governance (origin, quality, representativeness), technical documentation (purpose, architecture, training/tuning path, metrics, known limitations), operational records/logs, human oversight with clear points of intervention as well as requirements for accuracy, robustness, and cybersecurity. After the go-live comes post-market monitoring: Quality and incidents are monitored and reported promptly in the event of serious occurrences. For new releases, the following applies: Changes must be traceable, reviewed, and approved.
What about the basic models and generative AI (General Purpose AI, GPAI)? Here, the AI Act calls for transparency and due diligence at the model level: traceable documentation, appropriate security/robustness tests (e.g., red teaming), precautions against misuse, compliance with copyright rules (including TDM opt-out), as well as information that allows the generated content to be marked. Very powerful models with potential systemic risks are subject to additional obligations (enhanced evaluation and reporting requirements). In practice, this means that quality, security, and origin are addressed even before product integration.
Whose responsibility is it? The AI Act distinguishes between providers (who bring AI systems to market), deployers (who use them), and importers and distributors. Providers carry the main responsibility for design, training, documentation, and compliance. Deployers are responsible for ensuring that the systems are used as intended. This includes transparency for users, appropriate data, logging, supervision, and complaints. Those who combine both roles (e.g., internal development) fulfill both obligations.
How does a system enter the market? Through conformity and, for high risk, a CE mark in accordance with a standardized procedure, if applicable. The AI Act relies heavily on harmonized standards and codes of practice: Those who apply them can pragmatically verify conformity. There are also AI sandboxes and opportunities for real-world testing under supervision so that innovation is not stifled.
The schedule is the operational guideline, as the AI Act has been in effect since August 1, 2024. Prohibitions and measures relating to AI literacy have been in effect since February 2, 2025, and obligations for basic models and generative AI have been in effect since August 2, 2025. As of August 2, 2026, the core obligations for high-risk systems will apply, with transition periods until 2027, provided that AI is a part of regulated products. In other words, 2025 is the year of firmly establishing the process with a focus on inventory, transparency in the UX, data and model visibility, monitoring, as well as clearly defined intervention points.
From the PDF to practice: How teams firmly establish the obligations
The law refers to risk management, data governance, documentation, human oversight, robustness, and incident management. In projects, we translate this into four persistent habits:
- Evidence chains instead of heroic deeds. Each AI function gets living documentation, which includes the purpose, data sources, training/tuning process, versions, metrics, acceptance criteria, and known limitations. None of these things should just be written in the meeting minutes – they must be versioned, findable, and verifiable.
- Transparency as a UX feature. A clear notice that states “You are chatting with AI” does not cost any revenue, but it does increase trust. The same applies to displays of sources for generative responses or watermarks for synthetic media. Transparency equals product quality.
- Human-in-the-loop is a process, not a button. Define when humans intervene (thresholds, uncertainty, complaints), who is responsible, and how decisions are documented. Train people for this role – it is not a side job.
- It is monitoring as for payment transactions. Not just “works/does not work”, but quality and context. It means drift alarms, anomalies, security events, and retention times that serve both data protection and obligations to provide proof. Incidents are rehearsed, not just described.
Three stories from everyday life
Recruiting AI: find suitable profiles faster, without blind spots
A medium-sized company uses a model that presorts applications. The area of application clearly falls within the high-risk category (employment). What does this mean in operational terms?
You need a robust data and model history: Where does the training and test data come from? How representative are they in terms of the age, gender, and origin of the applicants? Which metrics do you secure before the go-live (e.g., false alarms per group)? Then the runtime phase begins: records of submissions/decisions, a human final authority for borderline cases, and clear channels for complaints and corrections. The goal is traceability – not perfect fairness at the touch of a button, but verifiable, continuous improvement.
How do we put this into practice? In our projects, we document all experiments and data cuts, let bias checks run before each release, and define strict acceptance criteria. Amazon SageMaker Clarify provides a solid first line of defense for bias analysis and explanations, while Model Monitor helps detect drift. For the audit trail, we use CloudTrail logs and application logs and keep them in compliance with data protection regulations. What’s important here is that the HR department is not a spectator, but rather a co-owner of the criteria.
Customer chatbot: helpful and clearly recognizable as AI
An e-commerce team relies on an assistant for questions about products. This is not high risk, but it does require transparency. The chat must make it clear that an AI is responding. Synthetic images or audio must be labeled as such. What is often underestimated are guardrails. Customers expect outputs in the areas of medicine and law to be restricted, aggressive language to be curbed, and sensitive data to be protected.
In practice, we establish a “Policy as Product” mindset: We clearly state what the bot is and is not allowed to do, test typical attacks (prompt injection, PII leaks), and firmly establish alternative paths to the human operator. To do this on AWS, we like to use Amazon Bedrock Guardrails (for content and security guidelines) and a RAG architecture with source references. The visible added value is that responses remain within the company’s fact room, and users can immediately see where a statement comes from.
Visual quality control in the factory: robust, and not just on the test bench
A camera system detects paint defects. This may not sound critical, but it can be high risk if the paint is a safety-relevant feature in a regulated product. In this case, good offline scores are not enough. This requires operational robustness: various lighting conditions, dirt, perspectives. We therefore plan rechargeable test batteries, define environmental variables (“What happens if there is dust on the lens?”), and specify rollback paths in case the defect rate suddenly increases. The telemetry flows into a monitoring system that monitors not only accuracy but also context (e.g., belt speed, camera heat). This brings incidents to light at an early stage, complete with a reporting process.
From the AWS perspective: AWS is helpful when it supports the process
When we look at the EU AI Act from the perspective of AWS, we have three very practical levers with regard to AI: Establish an evidence chain, create transparency and protection, and ensure operation and verification. The common thread is always the same: First, we define the process (purpose, risks, oversight, reporting channels), then we lay the appropriate AWS building blocks underneath it.
Establish an evidence chain. Amazon SageMaker provides the traceability required by the AI Act. With experiments and lineage, we record training and tuning steps without any gaps. The model registry stores versions, the release status, and the associated evaluation reports. Pipelines ensure that a successful run is reproducible, including specified acceptance criteria. Amazon SageMaker Clarify provides robust bias and explainability analyses before and after training; deviations are stored as findings and are part of the release. Datasets are stored as versions in Amazon S3 (optionally with Object Lock), while Amazon Lake Formation handles access and responsibilities. This turns “We believe it fits” into a verifiable state: The purpose, data origin, metrics, limits, and responsible parties can be retrieved at any time.
Create transparency and protection. For generative components, we use Amazon Bedrock: curated models and Amazon Bedrock Guardrails to prevent undesirable content, PII disclosures, or unsafe response modes. Using the Model Evaluation Tool makes quality and security tests repeatable. When facts matter, we integrate corporate knowledge by using RAG/knowledge bases. Responses come with sources that are displayed in the user interface. We deliberately resolve the statutory marking requirement (“You are chatting with AI” or references to synthetic media) in the UX and add metadata to the responses. Macie (S3 PII detection) and, if necessary, upstream PII detectors check the data that leaves the system. Logs document which protective measures were taken and when.
Ensure operation and verification. In operations, quality, security, and verifiability are what count. Model Monitor monitors the input data and predictions for drift. CIoudWatch collects metrics and triggers alarms, while CloudTrail records changes to resources and endpoints. The search and analysis workflows run on OpenSearch. Security Hub, GuardDuty, and Config detect faulty configurations and anomalies. KMS and IAM secure the keys and access, while VPC/PrivateLink separates the networks. For audits, Audit Manager collects the evidence based on defined controls. Lifecycle rules in S3 retain logs for an appropriate period of time – documented and in compliance with data protection regulations. EventBridge and Systems Manager orchestrate incidents from initial classification and notification all the way to model rollback. Where human decision-making is required, we use Amazon A2I (Augmented AI) to establish a verifiable review path with thresholds, scores, and training for reviewers.
The result is not a technology stack for its own sake, but an operational verification flow: from the data source to the model all the way to the decision, and back again if something needs to be corrected.
What teams should do now
Start with an honest inventory: Where is AI involved in your products and processes? Classify the use cases according to risk categories and mark those that will require special attention in 2025/26. Set up living documentation and close gaps in the data origin and metrics. Bring transparency into the user interface of your assistants – simple, but visible. Specify oversight points and train the role. And establish a two-stage monitoring process: quality metrics plus security/compliance signals. Keep the logs for as long as necessary – justified, documented, data protection-compliant.
Summary
The EU AI Act is not an obstacle, but rather a framework for scalable quality. Those who build their evidence chain today see transparency as user experience (UX), and take monitoring seriously, deliver faster – and sleep better. The tech stack (whether AWS or elsewhere) is interchangeable. However, discipline in data, documentation, and operations is not.
Skaylink supports companies along the entire AI journey, from use case prioritization and AI readiness to implementation and operation on AWS (e.g., with Amazon Bedrock/SageMaker) to governance, security, and operations.
Case stories
Chatbots and AI hallucinations: Building precision and trust with AWS Bedrock
Skaylink achieves AWS Generative AI Competency
Unleashing the power of NetApp ONTAP on AWS with Skaylink
AWS European Sovereign Cloud: Skaylink becomes a launch partner
Rethinking SaaS: Can managed cloud hosting be a path to digital sovereignty?
Cloud backup strategies – security starts with planning
Skaylink achieves the AWS Digital Sovereignty Competency
Be prepared when it counts most – with AWS Backup
Take the leap into cloud with MAP
ISG Multi Public Cloud Leader 2024
Transforming remote desktop solutions – a cloud-native approach
