The EU AI Act has entered another important stage of application. From 2 August 2026, new requirements apply, including transparency obligations for certain AI systems and AI-generated or manipulated content. At the same time, some deadlines concerning high-risk AI systems have been postponed.
For businesses using artificial intelligence, this means more than reviewing another piece of regulation. If a chatbot supports customers, a model generates content, AI is integrated into an existing application, or an AI agent can perform actions through enterprise APIs, regulatory requirements may translate into specific decisions concerning UX, architecture, data, integrations, testing, monitoring and access control.
Key takeaway for CIOs and CTOs: the AI Act is not only a Legal and Compliance topic. Once regulatory requirements have to be implemented in a production system, they also become a concern for architecture, development, Data, UX/UI, QA, DevOps and the teams responsible for maintaining the solution.
Legal status: 10 August 2026
This article presents a technology perspective on preparing AI systems and does not constitute legal advice. The classification of a system and the interpretation of specific regulatory obligations should be confirmed with your Legal or Compliance team.
EU AI Act 2026: what actually happened on 2 August?
The AI Act has been designed to apply in stages. Saying that “the AI Act came into force on 2 August 2026” is therefore an oversimplification.
Some provisions had already started to apply earlier. Since 2 February 2025, for example, certain prohibitions on unacceptable AI practices and requirements related to AI literacy have applied.
From 2 August 2026, another important group of rules started to apply, including the transparency obligations under Article 50 of the AI Act. The European Commission also published final guidelines explaining the scope of these requirements.
The transparency requirements cover, among other things:
- informing people when they are interacting directly with certain AI systems, unless this is obvious from the circumstances,
- technical marking by providers of certain AI-generated or manipulated content,
- disclosure requirements concerning deepfakes,
- specific cases involving AI-generated text published to inform the public about matters of public interest,
- informing people exposed to certain emotion recognition or biometric categorisation systems.
This does not mean that every requirement of the AI Act started to apply at the same time.
What about high-risk AI systems?
The implementation schedule for high-risk AI systems has changed. According to the current timetable, the requirements concerning high-risk AI systems listed in Annex III are to apply from 2 December 2027. For certain high-risk AI systems related to products covered by EU product safety legislation, the relevant deadline has been moved to 2 August 2028.
Practical takeaway: postponed deadlines should not be interpreted as a reason to postpone preparation. Adapting a system may require changes to architecture, data, documentation, vendor agreements, development processes and monitoring mechanisms.
What is changing in Poland?
Poland’s Act on Artificial Intelligence Systems establishes national mechanisms for supervising the AI market and implementing the EU framework. For organisations operating in Poland, August 2026 is therefore a good time not only to review legal documentation, but also to perform a technical review of how AI is actually used across the organisation.
For current regulatory information, organisations should rely primarily on official sources such as the European Commission, the AI Act Service Desk and, for organisations operating in Poland, the relevant national authorities.
EU AI Act: are we a provider or a deployer?
One of the first questions should not be: “Which requirements does our model meet?” The starting point is to determine the organisation’s role in relation to the specific AI system.
01 We build our own AI systemAssess whether the organisation acts as a provider in this particular scenario. | 02 We use a third-party AI systemAssess the obligations of the deployer and the responsibilities of the system provider. | 03 We modify an existing solutionIf the system, its intended purpose or the way it is used changes, reassess the organisation’s role. |
The AI Act distinguishes, among others, between a provider and a deployer. In simplified terms, a provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority in the course of its activities.
It is therefore risky to assume that using a third-party model automatically removes responsibility from the organisation. At the same time, simply integrating an external model through an API does not automatically make the organisation a provider.
Important: the role should be assessed for the specific system, implementation model and intended use. Borderline cases should be confirmed with Legal or Compliance.
What does the AI Act mean for an existing application or system?
It is possible to analyse the regulation article by article. From a CIO or CTO perspective, however, a more practical question is: which parts of our technology environment should we review?
The table below is not a legal compliance checklist. It highlights technical areas worth reviewing when regulatory requirements need to be translated into a production system.
| Area | CIO/CTO question | What should be reviewed technically? |
|---|---|---|
| Interaction with AI | Does the user know they are interacting with AI? | UI, UX, placement and timing of disclosure, accessibility. |
| Content generation | Can we preserve information about the origin of the output? | Metadata, machine-readable marking, content provenance, provider integration. |
| Integrations | Where can AI initiate actions? | APIs, permissions, tool access, scope of privileges. |
| Data | Which data does the system use? | Sources, access control, lineage, personal data. |
| QA | How do we verify the system’s behaviour? | Test scenarios, regression testing, AI evaluation, integration testing. |
| Monitoring | Can we see what happens after deployment? | Observability, alerting, versioning, logging. |
| Human oversight | Where can a person take control of the process? | Workflow, escalation, approval, override. |
| Vendor management | What does the model or system provider support? | Documentation, marking mechanisms, API capabilities, update policies. |
A regulatory requirement is not the same as a specific technical tool. The AI Act does not simply require an organisation to “implement observability” or use a particular QA framework. The technology environment does, however, need to enable the organisation to meet the requirements applicable to its specific use case.
A company deploys an AI chatbot for customer service. What should it check?
A chatbot is a useful example because the implementation can initially appear simple:
Model → API → application → data → user
Under Article 50, AI systems intended to interact directly with people should be designed so that the person concerned is informed that they are interacting with an AI system, unless this is obvious from the circumstances and context of use.
From a product perspective, the question is therefore not only:
“Have we added a message saying that the user is interacting with AI?”
The team should also consider how transparency affects UX, accessibility, integrations, data, permissions, QA, monitoring and human handover.
| Area | What is worth checking? |
|---|---|
| UX/UI | Where and when is the AI disclosure shown? Is it clear without unnecessarily disrupting the user’s task? |
| Accessibility | Is the information accessible to people using assistive technologies? |
| Integrations | Does the chatbot only respond, or can it also perform operations in CRM, ERP or other business systems? |
| Permissions | Which tools, functions and data can the model or agent access? |
| Data | Does the system use CRM data, customer history, internal documents or personal data? |
| QA | What happens when the user enters an unusual instruction, attempts to bypass restrictions or receives an incorrect response? |
| Monitoring | Can we detect deteriorating response quality or problems with connected data sources? |
| Human handover | When should a human take over, and how does escalation work? |
AI-generated content: why the problem does not end with a label
Another scenario concerns systems that generate content. Article 50 introduces specific transparency requirements for certain synthetic, AI-generated or AI-manipulated content.
For the technology team, however, there is an additional question:
Will information about the origin of the content survive the entire processing pipeline?
Imagine an application that:
|
01 Generates an asset using an AI model |
02 Retrieves it through an API |
03 Processes or converts it |
|
04 Stores it in a DAM |
05 Sends it to a CMS |
06 Publishes it across multiple channels |
The fact that the model provider supplies a technical marking mechanism does not automatically mean that the entire downstream pipeline will preserve it.
Questions worth checking include:
- What information is supplied by the AI provider?
- Does the API pass the relevant information downstream?
- What happens to metadata when a file is transformed?
- Does the CMS or DAM preserve provenance?
- Can conversion or optimisation remove relevant information?
- Can the organisation reconstruct how a particular asset was created and processed?
This is not a universal list of obligations arising directly from Article 50. These are architectural and operational questions that help determine whether the organisation’s own technology stack may remove or interfere with mechanisms used to meet specific transparency requirements.
EU AI Act: technical readiness checklist for CIOs and CTOs
An AI Act review should start not with individual models, but with an inventory of how AI is used across the organisation.
- Do we know where AI is being used across the organisation?
- Have we identified our role in relation to each AI system?
- Does the AI system interact directly with users?
- Does it generate or modify text, images, audio or video?
- Do we know which transparency mechanisms are provided by the AI vendor?
- Does the system have a human override or escalation path where one is required?
- Can we identify which model version, configuration, prompts and data sources were used at a specific point in time?
- Does QA cover the behaviour of AI components, not only the surrounding application?
- Can monitoring detect failures, anomalies or deterioration in system quality?
- Do changes to the model, provider, prompts or integrations go through a controlled release process?
Important distinction: not every item above is a direct obligation under Article 50 of the AI Act. Some are engineering and governance practices that help an organisation maintain control over an AI system and implement the requirements applicable to its specific use case.
A useful sequence is therefore:
System → organisation’s role → use case → applicable requirements → technical implementation
Why is the AI Act also an architecture problem?
A regulation cannot implement transparency or system controls by itself. When a requirement has to work in a production environment, it often needs to be translated into code, configuration, architecture or a technology process.
| Need | Potential technical implementation |
|---|---|
| User transparency | UI / UX / accessibility |
| Access control | Permissions / authorisation / APIs |
| Content provenance | Metadata / provenance mechanisms |
| Human control | Workflow / approval / escalation |
| System traceability | Logging / observability / monitoring |
| Controlled AI updates | Versioning / CI/CD / release management |
| Behaviour verification | QA / AI evaluation / regression testing |
In an enterprise environment, AI Act readiness requires collaboration between:
Legal / Compliance + Security + Architecture + Development + Data + QA + DevOps + Product.
Only then can the organisation answer two separate questions:
- Do we know which requirements apply to our solution?
- Is our system technically capable of meeting them?
We already have an AI system in production. What should we do now?
Not every production system needs to be rebuilt from scratch. A more practical approach is to move through a structured review and remediation process.
| Stage | What do we do? | Outcome |
|---|---|---|
| 1. Inventory | Identify systems, applications and functions that use AI. | AI inventory. |
| 2. Classify | Identify intended purpose, roles, users, data and actions performed by the system. | Information required for legal and technical classification. |
| 3. Gap analysis | Compare applicable requirements with the actual architecture and processes. | Identified gaps and priorities. |
| 4. Remediation | Design the required changes to UI, APIs, data, workflows and infrastructure. | Technical remediation plan. |
| 5. Test | Verify the solution end-to-end. | Validated system behaviour. |
| 6. Deploy | Release the changes through a controlled deployment process. | Controlled production release. |
| 7. Monitor | Monitor the model, integrations, data and system behaviour. | Ongoing control and visibility. |
AI readiness is not a one-off project. Models, APIs, data, prompts and connected systems continue to change after go-live. Governance, QA and monitoring should therefore remain part of the solution lifecycle.
How can Edge One Solutions support the technical preparation of an AI system?
At Edge One Solutions, we approach AI-related requirements primarily from a technology perspective. We do not replace Legal or Compliance teams. Instead, we help address the next question:
What needs to change technically once we know which requirements the solution has to meet?
Depending on the architecture and use case, this may involve changes to an application, new integrations, improvements to the data layer, UX/UI changes, additional testing, observability mechanisms or a different operating model for maintaining the system.
AI & DataSolution architecture, data preparation and integration of AI components with existing enterprise environments. | Custom Development & IntegrationsChanges to applications, APIs, workflows and enterprise integrations. |
UX/UI & QADesigning transparent user interactions and testing the behaviour of AI-enabled systems. | DevOps & Managed ServicesVersioning, controlled releases, monitoring, observability and ongoing support after go-live. |
If your organisation is still assessing whether its business, systems and data are ready for AI, see our AI Readiness for Enterprises checklist. For the wider governance perspective, read Ethics, regulations, and responsible artificial intelligence in business – what every CIO needs to know.
You can also explore our guide to legacy system modernisation for AI if existing applications, data structures or integrations are limiting your ability to deploy AI safely and reliably.
Is your AI system technically ready for the new requirements?
If you already know which requirements apply to your solution but are unsure how to translate them into architecture, integrations, UX, testing or monitoring, we can help assess the existing environment and plan the required technical changes.
