{"id":89545,"date":"2025-09-24T09:25:33","date_gmt":"2025-09-24T07:25:33","guid":{"rendered":"https:\/\/www.skaylink.com\/?p=89545"},"modified":"2025-09-24T09:27:54","modified_gmt":"2025-09-24T07:27:54","slug":"eu-ai-act-practice-aws","status":"publish","type":"post","link":"https:\/\/www.skaylink.com\/en\/insights\/blog\/eu-ai-act-practice-aws\/","title":{"rendered":"EU AI Act: Achieve compliance and transparency with AWS"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Home<\/a><\/span><\/span><\/p>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Blog<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

EU AI Act: Achieve compliance and transparency with AWS<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tThe EU AI Act is changing the way AI is handled. Companies can put the requirements into practice with AWS services such as Bedrock and SageMaker.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tSeptember 24, 2025\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\"Picture\n\t\t\t\t<\/div>\n\t\t\t\n\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tArtur Schneider\t\t\t\t\t\t<\/span>\n\t\t\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t

AWS Consultant<\/p>\n\t\t\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\n\t\t\t
\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Monday, 8:12\u00a0a.m. The Slack channel \u201cgo-live\u201d is exploding. The HR bot is scheduled to appear on the homepage today. \u201cAre we still allowed to do that? The EU AI Act is now in effect,\u201d writes the Legal department. Five minutes later, the Production team reports in: \u201cOur vision model is suddenly producing more false positives. Do we need to report an incident?\u201d Then marketing asks whether the AI-generated images in the fall campaign need to be labeled.<\/p>\n

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<\/strong>: With a clear purpose, data under control, managed risks, and measurable quality.<\/p>\n

The good news is that this can be done. However, this is only possible if teams understand transparency as a UX feature \u2013 that is, honestly communicate that an AI is responding and cite the relevant sources \u2013 build an evidence chain<\/strong> from the dataset to the decision, and monitor not only whether the system is \u201crunning\u201d but also its quality, drift, and security<\/strong>. This is exactly what the AI Act is useful for: It makes AI predictable for products, legal matters, and operations.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

What the law really wants (without legal jargon)<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

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<\/strong> for a \u201climited risk\u201d to extensive requirements for high-risk systems<\/strong>.<\/p>\n

What is off limits? Practices that are a structural violation of fundamental rights, such as \u201cuntargeted\u201d 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.<\/p>\n

What does \u201clow\/limited risk\u201d mean? Many everyday assistants. Here is where the AI Act demands transparency<\/strong> 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.<\/p>\n

Where does high risk<\/strong> 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<\/strong> throughout the entire life cycle: Documented risk management<\/strong>, data governance<\/strong> (origin, quality, representativeness), technical documentation<\/strong> (purpose, architecture, training\/tuning path, metrics, known limitations), operational records\/logs<\/strong>, human oversight<\/strong> with clear points of intervention as well as requirements for accuracy, robustness, and cybersecurity<\/strong>. After the go-live comes post-market monitoring<\/strong>: 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.<\/p>\n

What about the basic models and generative AI (General Purpose AI, GPAI)<\/strong>? Here, the AI Act calls for transparency and due diligence at the model level: traceable documentation, appropriate security\/robustness tests<\/strong> (e.g., red teaming), precautions against misuse, compliance with copyright rules<\/strong> (including TDM opt-out), as well as information that allows the generated content to be marked<\/strong>. Very powerful models with potential systemic risks<\/strong> 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.<\/p>\n

Whose responsibility is it? The AI Act distinguishes between providers<\/strong> (who bring AI systems to market), deployers<\/strong> (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. \u00a0Those who combine both roles (e.g., internal development) fulfill both obligations.<\/p>\n

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\u00a0sandboxes and opportunities for real-world testing under supervision so that innovation is not stifled.<\/p>\n

The schedule is the operational guideline, as the AI Act has been in effect since August\u00a01, 2024. Prohibitions and measures relating to AI literacy have been in effect since February\u00a02, 2025, and obligations for basic models and generative AI have been in effect since August\u00a02, 2025. As of August\u00a02, 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.<\/p>\n

From the PDF to practice: How teams firmly establish the obligations<\/h5>\n

The law refers to risk management, data governance, documentation, human oversight, robustness, and incident management. In projects, we translate this into four persistent habits:<\/p>\n

    \n
  1. Evidence chains instead of heroic deeds.<\/strong> 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 \u2013 they must be versioned, findable, and verifiable.<\/li>\n
  2. Transparency as a UX feature.<\/strong> A clear notice that states \u201cYou are chatting with AI\u201d 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.<\/li>\n
  3. Human-in-the-loop is a process, not a button.<\/strong> Define when humans intervene (thresholds, uncertainty, complaints), who is responsible, and how decisions are documented. Train people for this role \u2013 it is not a side job.<\/li>\n
  4. It is monitoring as for payment transactions.<\/strong> Not just \u201cworks\/does not work\u201d, 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.<\/li>\n<\/ol>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Three stories from everyday life<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t
    Recruiting AI: find suitable profiles faster, without blind spots<\/strong><\/h5>\n

    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?<\/p>\n

    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 \u2013 not perfect fairness at the touch of a button, but verifiable, continuous improvement.<\/p>\n

    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\u2019s important here is that the HR department is not a spectator, but rather a co-owner of the criteria.<\/p>\n

    Customer chatbot: helpful and clearly recognizable as AI<\/strong><\/h5>\n

    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.<\/p>\n

    In practice, we establish a \u201cPolicy as Product\u201d<\/strong> 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\u2019s fact room, and users can immediately see where a statement comes from.<\/p>\n

    Visual quality control in the factory: robust, and not just on the test bench<\/strong><\/h5>\n

    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 (\u201cWhat happens if there is dust on the lens?\u201d), 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.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    From the AWS perspective: AWS is helpful when it supports the process<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    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.<\/p>\n

    Establish an evidence chain.<\/strong> 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 \u201cWe believe it fits\u201d into a verifiable state: The purpose, data origin, metrics, limits, and responsible parties can be retrieved at any time.<\/p>\n

    Create transparency and protection.<\/strong> For generative components, we use Amazon Bedrock<\/strong>: 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 (\u201cYou are chatting with AI\u201d 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.<\/p>\n

    Ensure operation and verification.<\/strong> 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 \u2013 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.<\/p>\n

    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.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    What teams should do now<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    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 \u2013 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 \u2013 justified, documented, data protection-compliant.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    Summary<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    The EU AI Act is not an obstacle, but rather a framework for scalable quality<\/strong>. Those who build their evidence chain today see transparency as user experience (UX), and take monitoring seriously, deliver faster \u2013 and sleep better. The tech stack (whether AWS or elsewhere) is interchangeable. However, discipline in data, documentation, and operations is not.<\/p>\n

    Skaylink<\/strong> supports companies along the entire AI journey<\/strong>, from use case prioritization and AI readiness to implementation and operation on AWS (e.g., with Amazon Bedrock\/SageMaker) to governance, security, and operations<\/strong>.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

    \n\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Case stories<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t