top of page

If Even One Person in Your Company Uses Artificial Intelligence: The EU AI Act Concerns You More Than You Think

Şirketinizde Bir Kişi Bile Yapay Zeka Kullanıyorsa: AB AI Act Sizi Sandığınızdan Daha Fazla İlgilendiriyor
If Even One Person in Your Company Uses Artificial Intelligence: The EU AI Act Concerns You More Than You Think
This article has been written in accordance with the legal situation in force as of 30 July 2026. If you have researched the issue before, I would like to begin with a warning: a significant portion of the analyses you have in hand are no longer valid. Regulation (EU) 2026/1744 — Digital Omnibus on AI, is a regulation dated 8 July 2026, published in the L series of the Official Journal on 24 July 2026, and entered into force on 27 July 2026. It is the first amendment the AI Act has undergone since its adoption in 2024. The AI Act you are reading today is not the 2024 text; it is the amended version of the 2024 text. This distinction is decisive particularly with regard to Article 4: the legal nature of the obligation has changed, and most of the content currently in circulation still explains the old text.

Artificial intelligence today enters companies not as a “major transformation project,” but often quietly. An employee prepares an email draft with artificial intelligence; the sales team produces proposal text; the project manager has meeting notes summarised; the marketing department creates visuals; an independent consultant accelerates a client presentation with generative AI. Corporate risk begins precisely here: as the use of technology becomes invisible, responsibility does not disappear; on the contrary, it grows.


At this point, the European Union’s AI Act sends a clear message: the person and organisation using artificial intelligence must possess a level of literacy sufficient to understand what they are doing and what they are putting at risk. However, the legal nature of this obligation has changed with the Digital Omnibus. Article 4 is no longer an obligation to “ensure a sufficient level of literacy,” but an obligation to “take measures that support the development of literacy.” In other words, it is no longer an obligation of result, but an obligation of effort.


This does not mean that the obligation has disappeared; it remains binding, without exception, for every provider and every deployer. What has changed is the very question that will be asked of you during supervision: it is no longer “Is your employee’s literacy level sufficient?” but “What measures did you take, and how are you proving this?”


This distinction shifts the centre of gravity of corporate preparedness. Instead of chasing a measurable threshold of sufficiency, it becomes necessary to build a measures architecture that is designed, reasoned, and documented. In my experience, for most companies, this is not easier; it is a more disciplined task.

Current Legal Status and Application Timeline


The EU AI Act, namely Regulation (EU) 2024/1689, entered into force on 1 August 2024 and was tied to a phased application timeline. Provisions concerning prohibited AI practices and AI literacy have applied since 2 February 2025. As of 2 August 2025, the rules relating to general-purpose AI models, governance structures, and the penalty regime under Article 99 entered into force.


This timetable was rewritten on 24 July 2026. By Article 1(40), Regulation (EU) 2026/1744 amended the third paragraph of Article 113 of the AI Act; it postponed obligations relating to high-risk systems, while leaving the general application date in place. Technically, the scope of the postponement is clear: only Parts 1, 2, and 3 of Chapter III have been postponed (except Article 6(5)).


The choice of urgent entry into force in the Regulation is also meaningful. Instead of the ordinary twenty-day period, the text entered into force on the third day following publication; the justification in Recital 46 is to remove legal uncertainty without delay in view of the proximity of the general application date of 2 August 2026. This is an unusual sign of urgency in EU legislative practice.


Entry into force and applicability are not the same thing


This distinction must be kept strict, because public discussion constantly confuses the two. On 27 July 2026, the amendments became part of the AI Act text; however, not every amended provision became enforceable at the same time. The only group of provisions that the Regulation expressly made applicable from 27 July are Articles 102–110 of the AI Act (new Article 113(3)(d)).


For everything else, the Article 113 timetable continues to operate provision by provision:

  • Chapter I provisions (Articles 2, 3, 4, and new Article 4a) have applied since 2 February 2025 and therefore take effect in their amended form together with entry into force.

  • The same logic applies to the sections that have applied since 2 August 2025.

  • Chapter III, Parts 1–3 provisions (including Articles 6, 10, 11, 17, 25, 26, and 27) are postponed to 2 December 2027 or 2 August 2028 depending on the classification of the system.

  • The provisions that apply from 2 August 2026 — Articles 40, 42, 43, Article 50, 57, 58, 60, new Article 60a, Article 72, Article 75, and new Articles 75a–75d — become enforceable on that date.


Making this distinction explicit in a corporate roadmap prevents from the outset the false sense of comfort created by the statement “the AI Act has been postponed.” The AI Act has not been postponed. What has been postponed are the parts relating to high-risk systems, operator obligations, and notified bodies.


Updated timetable table

Date

What applies

Legal basis

2 February 2025

Prohibited practices (Article 5) and AI literacy (Article 4). They continue to apply.

Art. 113(3)(a), AI Act (original)

2 August 2025

GPAI model rules, governance structures, Article 99 penalty regime.

Art. 113(3)(b)

27 July 2026

Reg. 2026/1744 enters into force; the amendments become part of the AI Act text. Articles 102–110 apply expressly. The softened version of Article 4 and new Article 4a take effect.

Art. 4, Reg. 2026/1744; Art. 113(3)(d)

2 August 2026

General application date — unchanged. Article 50 transparency obligations, governance framework, and powers under Article 75 and Articles 75a–75d take effect.

Art. 113, second and third paragraphs

2 December 2026

The new prohibitions in Article 5(1)(ba) and (bb), and new Article 5(1a) and 5(1b), apply. By the same date, providers of systems placed on the market before 2 August 2026 that generate synthetic audio/image/video/text must take the necessary steps to comply with the machine-readable marking obligation in Article 50(2).

Art. 113(3)(a); Art. 111(4)

1 August 2027

Deadline for the Commission to publish implementation guidance coordinated with Annex I, Part A legislation.

Art. 96(1)(g)

2 August 2027

Adoption of delegated acts on the equivalence clause. At least one regulatory sandbox to be operational at national level.

Art. 2(13); Art. 57(1)

2 September 2027

Commission guidance and template for the post-market monitoring plan.

Art. 72(3)

2 December 2027

Chapter III, Parts 1–3 apply to standalone high-risk systems under Annex III (except Article 6(5)). Previous date: 2 August 2026.

Art. 113(3)(c)(i)

28 January 2028

Deadline for notified bodies under Annex I, Part A to apply for designation under the AI Act.

Art. 43(3)

2 August 2028

Chapter III, Parts 1–3 apply to embedded high-risk systems under Annex I. Previous date: 2 August 2027.

Art. 113(3)(c)(ii)

2 August 2030

Deadline for providers and deployers of high-risk systems designed for use by public authorities.

Art. 111(2

A common misreading. Public discussion often says that the date of 2 August 2030 was “postponed” by the Digital Omnibus. The verifiable picture does not support this: the date in Article 111(2) was already an existing deadline and was not amended by the Omnibus. Marking this in a roadmap as “newly gained time” would create a false sense of comfort.


A second critical point: the postponement is unconditional. In the Commission’s original proposal, it was envisaged that the postponement would be linked to the readiness of harmonised standards. This conditional trigger was removed from the final text. That means 2 December 2027 and 2 August 2028 are fixed dates; the delay or early readiness of standards does not shift these dates. For them to change, a new legislative process would be required. From a planning perspective, this is better than uncertainty: budget can now be built around the timetable.


Be careful when reading old sources. In the majority of content published until mid-2026, two claims circulated, and both are now outdated. The first is the use of the date 2 August 2027 for obligations linked to Article 6(1); that date is now 2 August 2028. The second is the caution that the political agreement of 7 May 2026 had “not yet turned into binding text”; that agreement was approved by Parliament on 16 June 2026, by the Council on 29 June 2026, and was published in the Official Journal on 24 July. When looking at the consolidated text in EUR-Lex, it is therefore necessary to check the version date as well.


For companies today, the most critical threshold is still not the question “Has Article 4 started?” The question is: how will I make the measures I have taken demonstrable by 2 August 2026?


What Article 4 Says and What It Expects from Companies


This section is the part of the article that requires the most care, because Article 4 is both the most wide-reaching obligation in the AI Act — it binds every provider and every deployer, regardless of whether the system is high-risk — and it has also been completely rewritten by the Digital Omnibus.


What Article 4 was, and what it became

Seeing how much of the obligation changed and how much stayed the same is the quickest way to set the tone correctly in corporate communication.


Dimension

2 February 2025 – 27 July 2026 (original text)

From 27 July 2026 onward (amended text)

Verb of the obligation

Ensure a sufficient level of AI literacy

Take measures supporting the development of AI literacy

Legal nature

Obligation of result

Obligation of effort

Individual level requirement

A “sufficient level” is expected

No need to guarantee that any individual reaches a particular level

Who is bound

All providers and deployers

Unchanged

Who is covered

Employees + other persons working with AI on behalf of the organisation (contractors, service providers)

Unchanged

Assessment criteria

Technical knowledge, experience, education, context of use, groups of persons affected

Unchanged

Institutional support

Not foreseen

Commission and Member States tasked with support; publication of practical examples (new Art. 4(2))

Competence framework

Unclear

Board recommendations; explicit reference to DigComp (new Art. 4(3))

Mandatory certificate

None

Unchanged — none

Independent fine

None

Unchanged — none

Supervisory authority

National market surveillance authorities

Unchanged

Postponement

—

None. The new text applies directly on 27 July 2026

The “unchanged” rows in the right column are just as important as the changes in the left column. The obligation has been softened; it has not disappeared, and it remains universal.


The new structure of the obligation


Providers and deployers are no longer required to ensure a sufficient level of AI literacy. Instead, they are required to take measures to support the development of AI literacy among their staff and other persons dealing with AI systems on their behalf. In making this assessment, technical knowledge, experience, education, context of use, and the persons or groups on whom the system is to be used must be taken into account.


The text adds a sentence that leaves no room for doubt: the obligation does not require the provider or deployer to guarantee that any individual reaches a particular level of literacy.


Two incorrect conclusions should not be drawn from this. First, an obligation of effort does not mean “appearance is enough”; the effort itself must be designed, appropriate to the context, and documented. Purchasing a general training module from a vendor and considering the matter closed is an approach that would not satisfy even the softened text. Second, the scope of the obligation has not narrowed: it continues to cover not only employees, but also contractors and service providers working with AI on behalf of the organisation.


The new second and third paragraphs

The amendment did not merely soften the obligation; it also created a support architecture.


New Article 4(2) tasks the Commission and the Member States with supporting and facilitating the efforts of operators, especially SMEs, and provides for the publication of practical compliance examples on the single information platform envisaged in Article 62(3)(b).


New Article 4(3) tasks the European Artificial Intelligence Board with adopting recommendations that define common objectives while taking account of existing European competence frameworks. Recital 8 expressly refers among these frameworks to DigComp and the AI Literacy Framework for Primary and Secondary Education. For teams designing corporate training, this fills a reference point that had long remained empty: there is now an official signpost as to which competence taxonomy you may rely on.


Intertemporal law: an eighteen-month asymmetry

There is a technical point with practical consequences. The original, stricter version of Article 4 has applied since 2 February 2025. The new version applies from 27 July 2026, without any postponement. Operators were therefore bound for approximately eighteen months by a stricter provision than the one in force today.


The practical meaning of this is as follows: acts and omissions in the period between 2 February 2025 and 27 July 2026 are assessed according to the stricter standard that was in force during that period; the new and lighter text does not apply retroactively. It is therefore risky to liquidate past records on the basis that they are “no longer necessary.” This is one of those counter-intuitive points that must be explained to the board: because the legislation has softened, engaging in archive cleanup means losing protection.


The observation that Article 4 has never been supported by an independent fine provision is also meaningful here. For that reason, the effect of the softening is less about exposure to fines than about the documentary and organisational burden. The real source of pressure is not the administrative fine, but the prospect of having no answer to the question “What measures did you take?” in an employment court, a discrimination allegation, customer arbitration, or a negligence action. That is the message to communicate at executive level — not penalty, but silence.


The minimum compliance architecture is still standing

Before the Digital Omnibus, the Commission’s Article 4 guidance defined the following minimum architecture, and that architecture continues to function under the new text. An organisation should be able to provide corporate answers to the following questions: Which AI tools are used in the company? Is the organisation a provider or a deployer? What are the risks of these systems? How will training and guidance be differentiated according to the level of technical knowledge and the context of use?


The Commission stated that merely requiring people to read instructions for use may be ineffective in many cases; training and guidance should be designed according to the knowledge level and intended use of the target group. Its assessment that Article 4 applies even where employees use ChatGPT to write advertising copy or perform translation, and that information should be given about specific risks such as hallucination, also falls within this scope. This narrows the defence that “we only use it for simple tasks.”


There has been no change in the definitions. A provider is the actor that develops an AI system or has it developed and places it on the market or puts it into service under its own name or trademark. A deployer is the person that uses the AI system under its authority. If a Turkish company uses ChatGPT, Copilot, or similar third-party tools in its internal processes, it will typically be closer to the position of a deployer; if the same company begins offering an AI-supported tool to its customer under its own brand, it may also acquire the status of provider.


A source discrepancy on the supervision date

There is a one-day difference between sources concerning the start date of national supervision of Article 4. The Commission’s “AI talent, skills and literacy” policy page, updated after the Digital Omnibus, states that national market surveillance authorities will begin supervising and enforcing the rules as of 2 August 2026. By contrast, the Commission’s Article 4 Q&A of 7 May 2025 and secondary sources citing that text give the date 3 August 2026. For corporate planning, the prudent approach is to proceed on the basis of the earlier date (2 August 2026); operationally, the difference of one day is insignificant, but in legal communication it remains worth confirming.


Scope and Practical Implications for Turkey-Based Companies


For a Turkey-based company or freelancer, the main risk is not “not being established in the EU”; it is the output being used within the Union.


The Digital Omnibus did not alter this logic of extraterritorial effect. The AI Act applies to providers and deployers established in third countries where the output produced by the AI system is used in the EU. A Turkish freelancer producing AI-generated marketing content for a French client, a Turkish agency producing AI-supported text for German customer services, a consultancy company in Türkiye providing AI-supported decision notes to a Dutch client, or a SaaS provider producing AI outputs used by users within the EU may require an AI Act scope analysis. The decisive element is not the company’s passport, but the legal role of the AI system, its geographical connection, and the use of the output within the EU.


New Article 4A: a structural change in the personal data dimension


This is the least discussed but most significant innovation of the Digital Omnibus for Turkish companies. By Article 1(6), the Regulation adds a new Article 4A to the AI Act, and by Article 1(9), repeals Article 10(5).


This is not a simple relocation. The legal basis for the processing of special categories of personal data for the purpose of bias detection and correction has been removed from the provision on training data for high-risk systems and moved into Chapter I, with a significant expansion of the personal scope.

Paragraph 1 preserves the known regime for providers of high-risk systems subject to six cumulative conditions: the purpose cannot be achieved with other data including synthetic or anonymised data; technical restrictions on reuse and security and privacy-protective measures in line with the state of the art, including pseudonymisation; strict access controls and documentation; a prohibition on transmission, transfer, or access by other parties; deletion when the bias has been corrected or the storage period expires, whichever occurs first; and a strict necessity statement in the record of processing activities.


Paragraph 2 extends this possibility, under the same conditions, to providers and deployers of other AI systems and models and to deployers of high-risk systems; it also adds the condition that the processing must be strictly necessary in relation to biases likely to affect health and safety, undermine fundamental rights, or give rise to discrimination prohibited by Union law. The final sentence of the paragraph is critical: this provision does not create an obligation to perform bias detection and correction. It is a possibility, not a duty.


There is also an important point regarding temporal effect: Article 4a does not follow the postponement of Chapter III. It is usable from 27 July 2026 and does not wait for 2 December 2027 or 2 August 2028. The reasoning in Recital 9 is that this is necessary so that providers of high-risk systems may lawfully carry out these activities as part of their preparations for complying with Articles 10(2)(f) and (g).


Conversely, no conclusion may be drawn that Article 4a legitimises processing carried out before its entry into force; retroactive effect would have required an explicit transitional provision, and no such provision exists.


Practical warning for Turkish companies: Article 4a must be read together with GDPR Article 9(2)(g), Article 10(2)(g) of Regulation (EU) 2018/1725, and Article 10(a) of Directive (EU) 2016/680; it represents a privatisation of an important public interest, and is not an independent and self-sufficient legal basis. More importantly, it does not create a condition for processing under Law No. 6698. The regime concerning special categories of personal data under Article 6 of the KVKK must be assessed separately and independently. Where a Turkish company serving an EU client carries out a bias-correction activity relying on Article 4a, that processing will additionally require compliance with the KVKK insofar as the processing occurs in Türkiye. Confusing these two layers is one of the most common errors found in compliance documentation.


Consistently with this, Article 2(7) of the AI Act has also been amended, and in defining the relationship with the GDPR, Regulation (EU) 2018/1725, Directive 2002/58/EC, and Directive (EU) 2016/680, Articles 4a and 59 are now expressly preserved.


SME and small mid-cap regime: a concrete gain for one-person structures

The Digital Omnibus added two new definitions to Article 3 of the AI Act: SME, by reference to Article 2 of the Annex to Recommendation 2003/361/EC; and SMC (small mid-cap enterprise), by reference to point 2 of the Annex to Recommendation (EU) 2025/1099.


Their consequences are spread across the text and have direct significance for one-person consultancies and small agencies: simplified technical documentation and a template for it to be prepared by the Commission and accepted by notified bodies (Art. 11(1)); proportionality of the quality management system to the size of the organisation (Art. 17(2)); extension of the simplified conformity route previously available only to micro-enterprises to SMEs including start-ups (Art. 63(1)); priority access to sandboxes established by the AI Office (Art. 57(3a)); and attention to SME/SMC needs in Commission guidance and national authority guidance (Arts. 96 and 70(8)).


Reflection in business functions

When this picture is translated into business functions, four areas stand out. For marketing, the real risk lies not only in hallucination, copyright, and brand trust, but also in the logic of disclosure in public-facing content. The Article 50 transparency obligations retain their own timetable and enter into force on 2 August 2026. Informing people that they are interacting with AI, labelling deepfake content, and disclosing AI-generated texts published in order to inform the public on matters of public interest will be obligations from that date onward. The only exception concerns the machine-readable marking of synthetic content under Article 50(2): for systems placed on the market before 2 August 2026, the compliance period has been extended until 2 December 2026 (new Art. 111(4)). The logic that, where there is human editorial control and editorial responsibility, the obligation to disclose text may fall within an exception remains intact.


In Human Resources, Annex III expressly lists AI systems used for recruitment, the analysis and filtering of job applications, and candidate evaluation as high-risk. The timetable here has changed: the Chapter III obligations relating to these systems now apply on 2 December 2027. But this is not an exemption; it is additional time. Moreover, two things are already binding today: the obligation to take measures under Article 4 and the prohibitions in Article 5 — including the ban on emotion recognition in the workplace — have applied since 2 February 2025. It would be incorrect to tell an HR team, “we are safe until 2027.”


In sales, high-risk classification will often not arise; but this is not reassuring. Sales teams use AI for proposal text, email drafts, customer summaries, and presentation preparation. Hallucination, false promises, entry of customer data into a third-party tool, and uncertainty over “who performed the final review?” are the real risks in this area. The Commission’s assessment that staff should be informed about risks even in apparently ordinary uses directly supports this point.


In ERP/CRM consultancy, project management, and PMO, the central risk is invisible data leakage and the integrity of deliverables. Meeting notes, workshop summaries, test scenarios, user stories, project risk analyses, customer decision records, and defect reports often contain personal data, process secrets, or trade secrets. In this area, the softening of Article 4 makes nothing easier; because here the risk is not the administrative fine, but contractual liability and customer trust.


Local layer: KVKK

The second layer on the Turkish side is the local data protection and governance dimension, and it has not been affected by the Digital Omnibus. The announcement of the Turkish Personal Data Protection Authority dated 5 March 2026 entitled “Use of Generative Artificial Intelligence Tools in Workplaces,” and the related document, state that AI tools used outside corporate control create a shadow AI risk, and that it often becomes invisible which tools are used for which purposes, which kinds of data are entered, and how outputs are used. The same guidance emphasises that entering intellectual property and trade secrets into third-party AI tools may lead to rights violations and loss of control, that personal data and sensitive information may be reflected in outputs, and that hallucinations may cause incorrect or misleading content to enter business processes without being detected. It is stated that Law No. 6698 provides a technology-neutral framework and that data processing activities carried out through generative AI should also be assessed within this framework.


Three practical consequences follow. First, an AI inventory is no longer a corporate luxury; it is a minimum governance tool. Second, customer contracts and confidentiality provisions should be updated with regard to third-party AI use and the limits of reliance on AI outputs. Third, on the website, content production, and customer communication side, the Article 50 transparency rules must be taken into account as of 2 August 2026.

Supervision, Enforcement and the Action Plan Before 2 August 2026


Article 99: penalty ceilings remain, the framework expands

The main provision of the enforcement architecture is Article 99. Member States must establish effective, proportionate, and dissuasive measures for infringements. The ceilings remain: EUR 35 million or 7% of worldwide turnover for prohibited AI practices; EUR 15 million or 3% for certain provisions such as Articles 16, 22, 23, 24, 26, 31, 33, 34, and Article 50; and EUR 7.5 million or 1% for supplying incorrect or incomplete information.


The Digital Omnibus made two changes here. Article 99(1) was rewritten to state expressly that Member States shall lay down rules on penalties and other enforcement measures; that those may include administrative fines, warnings, and non-monetary measures; and that the economic sustainability of SMEs and SMCs must be taken into account. New Article 99(6a) provides that, for SMCs, each penalty under paragraphs 4 and 5 shall be limited to whichever is lower: the percentage or the fixed amount. This protection already existed for SMEs including start-ups; it has now been extended to small mid-cap enterprises as well.


Article 4 continues not to appear among the harmonised fine headings individually listed in Article 99(4). Therefore, the enforcement risk in Article 4 infringements continues to operate primarily through the national penalty and enforcement regimes of the Member States; supervision and enforcement are not in the AI Office, but before national market surveillance authorities.


The AI Office has become an enforcement authority

The largest part of the Digital Omnibus in terms of textual volume is not simplification. It is the construction of a supervisory and enforcement apparatus for the AI Office, and this is the innovation most often overlooked in corporate roadmaps.


Article 75 has been rewritten. Its title is now “Market surveillance and control of AI systems and mutual assistance”; and the new first paragraph grants the AI Office exclusive competence for two categories of systems:

  • AI systems based on general-purpose AI models, where the model and the system are developed by the same provider or by providers that are part of the same undertaking;

  • systems composing or integrated into very large online platforms or very large online search engines designated under Regulation (EU) 2022/2065 (DSA).


The expansion from “same provider” to “same undertaking” shows that the controversial point in the negotiations was resolved in favour of a broader interpretation. Four exceptions remain: systems relating to products covered by Annex I harmonisation legislation; systems under point 2 of Annex III; systems provided by law enforcement authorities, border management authorities, and financial institutions insofar as they fall within Article 74(6); and systems under point 8 of Annex III in relation to the administration of justice.


Exclusive competence in person applies to the providers of these systems and only extends to deployers if they are at the same time providers or are part of the same undertaking as the provider.


New Articles 75a–75d introduce four new layers of power:

  • Article 75a — supervisory and enforcement powers. The AI Office has all the powers of a market surveillance authority under the AI Act and Articles 14(4) and 16(3) of Regulation (EU) 2019/1020. It may launch investigations on its own initiative or upon complaint. It may request information by simple request or decision. It may carry out remote and on-site inspections; enter the operator’s premises, land and property within the Union; examine books and data in any medium; take copies; request oral or written explanations; and seal premises, books, and records during the inspection.

  • Article 75b — commitments. The operator may offer commitments; the AI Office may make them binding by decision.

  • Article 75c — non-compliance, fines, and periodic penalty payments. The penalties in Article 99(3)–(7) apply mutatis mutandis. Periodic penalty payments may not exceed, on a daily basis, 5% of the average daily income or worldwide annual turnover in the preceding financial year. The limitation period is five years.

  • Article 75d — safeguards. Rights of defence, access to file under a negotiated disclosure regime, publication of decisions.


Anyone who has dealt with competition law will recognise this architecture: in essence, it is the transfer of the antitrust procedural model into the field of AI. In terms of timing, note that Article 75 and Articles 75a–75d are located in Chapter IX of the AI Act, which applies from 2 August 2026. The amendments entered the text on 27 July, and the powers became usable one week later.


Added to this picture is Article 64(3), which provides that sufficient resources shall be allocated to the AI Office in order to enable it to perform its tasks effectively, but “without prejudice to the budgetary procedure.” Independent legal commentators point to this as the most fragile point in the design: an inspection power including the sealing of premises requires the administrative capacity to use it, and Article 64(3) does not guarantee that capacity.


Concrete control point for deployers: check whether you fall under Article 75(1). A deployer that is part of the same undertaking as the provider is, from 2 August 2026, subject to the exclusive supervision of the AI Office. This is not merely a change of competent authority; it is a change of your interlocutor.


Action plan between today and 2 August 2026

Period

Work to be performed

Expected output

Evidence / record

Immediately

Create an organisation-wide artificial intelligence usage inventory; separate approved and unapproved tools.

Visibility and ownership of use

Inventory table, system list

Immediately

Assess the provider or deployer role for each use scenario.

Corporate role map

Role-assessment note

Immediately

Identify the link with an EU customer, use in the EU, or impact on persons in the EU.

Geographical scope analysis

Customer and geography matrix

Immediately

Determine whether you fall within Article 75(1) (GPAI-based system, same undertaking link, VLOP/VLOSE integration).

Clarity on competent authority

Authority map and note of reasoning

Immediately

Classify data categories.

Data-risk map

Classification of personal data, special categories of personal data, trade secrets, and intellectual property

Immediately

Start AI literacy measures according to role and risk level and document the measures you have taken.

Article 4 effort-obligation infrastructure

Measures register, training materials, attendance and assessment records

Immediately

Do not dispose of literacy records relating to the period 2 February 2025 – 27 July 2026; archive them.

Protection under intertemporal law

Period archive record

Before 2 August 2026

Publish the AI usage policy and obtain employee acknowledgements.

Corporate governance framework

Policy, communication, and read/acknowledged records

Before 2 August 2026

Establish Article 50 disclosure rules for public AI content.

Transparency approach

Web, social media, and editorial disclosure standard

Before 2 August 2026

Establish an incident response and escalation flow.

Response readiness

Incident-management procedure, list of responsible persons

Before 2 December 2026

Implement the machine-readable marking required by Article 50(2) for systems placed on the market before 2 August 2026 that generate synthetic content.

Compliance with the transition under Article 111(4)

Technical design of marking and verification tests

Before 2 December 2026

Screen your systems inventory for the new prohibitions in Article 5(1)(ba) and (bb).

Prohibition compliance screening

Assessment note, record of technical safeguards

As the horizon of 2 December 2027 / 2 August 2028 approaches

Plan preparation for Annex III and Annex I high-risk systems according to the postponed but fixed timetable.

High-risk compliance programme

Gap analysis, project plan, budget record

Continuous

Review the policy, measures set, and inventory at least every six months.

Up-to-date governance structure

Revision record

Continuous

Operate an AI use approval process for each new tool, customer, or integration.

Change control

Request and approval form

Continuous

Connect incidents, near misses, customer complaints, and data breaches to the learning cycle.

Organisational learning

Incident record, root-cause analysis, and corrective actions

Evidence and Documentation Set


Artificial intelligence is now part not only of technology use, but also of the architecture of corporate governance. In its current form, Article 4 of the EU AI Act asks companies the following management question: “Who uses the AI you use, for what purpose, with what data, through which control mechanism, and what measures have you taken to develop the literacy of those persons?”


The final part of that question is the sign of a silent but important shift in the logic of proof. The original text expected you to prove a result; the current text expects you to prove a measure. The centre of gravity of your document set should be built accordingly: not examination scores and competence certificates, but the design of measures, the reasoning behind them, target group analysis, and records of implementation.


For companies that can answer this question in writing and in a demonstrable way, the 2026 threshold will be a manageable transition. For those that cannot, the risk will arise not from the use of technology, but from uncontrolled, unrecorded, and non-contractual use.


The following tables have been prepared on the basis of the European Commission’s minimum compliance framework for Article 4, the text of Articles 4 and 4a as amended by Regulation (EU) 2026/1744, the transparency obligations in Article 50, the human oversight expectations in Article 26, and the data-security governance approach in the KVKK’s workplace generative AI guidance. They do not constitute legal advice; however, they provide an applicable management set for duygusener.com readers.

Minimum Evidence and Documentation Set for Companies

The Commission’s Q&A is clear on the following point: no certificate is required under Article 4; companies may maintain internal records relating to training and guidance initiatives. This is an important advantage for small companies and one-person professional structures. In other words, the key to compliance is not expensive certification, but a demonstrable governance pathway.


In practice, the proposed minimum evidence set may be structured as follows:

Document

Minimum Content

Management Purpose

Artificial Intelligence Inventory

Tool, model, business unit, purpose, role, data type, EU connection, output area, human control

Demonstrating what is used within the organisation

Approved Tools List

Approved, restricted, and prohibited tools; conditions of use

Reducing shadow AI

Data Boundary Matrix

Data categories that may and may not be entered

Managing KVKK, confidentiality, and trade-secret risks

Role-Based Training Matrix

Role, risk, module, date, renewal frequency

Operationalising the Article 4 approach

Training Records

Participant, date, content version, assessment, and approval

Demonstrating the organisation’s training measures

Usage Policy

Rules relating to tools, data, human control, transparency, and incidents

Defining the corporate standard

Incident and Near-Miss Register

Incident, impact, cause, action, and lesson learned

Supporting continuous improvement

Customer / Supplier Contract Addendum

Use notification, confidentiality, human review, intellectual property, and incident notification

Managing third-party risk

Public Content Review Form

Content type, artificial intelligence contribution, human editorial control, disclosure decision

Recording the transparency approach

Management Review Record

Findings, open risks, decisions, and action owners

Demonstrating senior-management oversight


Minimum Set for One-Person Consultancies and Freelancers

The same logic may also be applied on a smaller scale in one-person consultancy or freelance structures. Even where one person is both the user and the person responsible for delivery, they do not fall outside the deployer definition where professional use is involved. For this reason, it is reasonable to maintain at least a mini inventory, a customer-data boundary note, a pre-delivery human-control checklist, and a disclosure rule for AI-supported public visuals and texts.

Template Name

Content

AI Inventory Form

Tool, purpose, department, customer/EU connection, data type, output type, control owner

AI Usage Policy

Purpose, scope, approved tools, prohibited inputs, human control, public disclosure, incident notification, customer-data boundary note

Pre-Delivery Checklist

Accuracy, confidentiality, copyright, contract, and human control

Incident Record

Incident type, data impact, contractual impact, customer impact, emergency suspension, corrective action

Contract Addendum

AI-use notification, confidential-information restriction, accuracy and human-review provision, incident notice, IP provision

Public Content Disclosure Rule

Which visuals and texts require disclosure

Incident Response Flow


Artificial intelligence governance is not limited to determining which tools may be used. The organisation must also define in advance how it will act when an artificial intelligence system produces an unexpected, incorrect, or harmful result. This is because an incident originating from artificial intelligence does not arise solely in the form of a cybersecurity breach.


A customer response containing incorrect or fabricated information, the transfer of personal data to a third-party tool, the unauthorised use of confidential project documents, an image carrying copyright risk, a discriminatory candidate assessment, or an incorrect decision recommendation may also be treated as a corporate artificial intelligence incident.


For this reason, the incident-management process should not be left solely to the Information Technology team. Legal, compliance, information security, the relevant business unit, data-protection officers, and, where necessary, senior management should be part of the same escalation chain.


Incident Response Flow
Incident Response Flow

First Step: Identify and Classify the Incident

When an incident is detected, the type of risk involved should first be determined.


The following issues should be considered together in the initial assessment:

  • Was an incorrect or misleading output produced?

  • Were personal data or special categories of personal data processed?

  • Is there a risk concerning trade secrets, customer information, or intellectual property?

  • Did a discriminatory, unfair, or fundamental-rights-related outcome arise?

  • Were system security or access controls breached?

  • Did the output reach the customer, employees, or the public?

  • Does the incident affect a contractual obligation?

  • Is the system used classified as a high-risk artificial intelligence system?


The objective is to direct the incident to the correct governance channel as quickly as possible.


Where There Is External Impact, Use Should Be Stopped or Suspended

Where the incident affects a customer, employee, the public, or third parties, temporary suspension or cessation of the relevant artificial intelligence use should be considered. For example, if an AI system used in customer service continuously provides incorrect guidance, merely correcting the outputs may not be sufficient. Until the cause of the problem is understood, the system’s function involving direct contact with the customer should be restricted.


Where there is no external impact and the risk is low, close monitoring, additional human control, and verification mechanisms may be applied. This decision should not be automatic; it should be made according to the severity of the risk and the context of use.


Internal Escalation Should Not Be Limited to a Single Department

AI incidents often affect multiple risk areas simultaneously. An incorrectly generated customer email may appear to be a quality problem; however, where the content includes personal data, trade secrets, or a commitment contrary to the contract, the incident also becomes a legal, data-protection, and reputational risk.


For this reason, the internal escalation line should include, at a minimum, the following functions:

  • Legal and compliance,

  • Information Technology,

  • Information security,

  • The relevant business unit,

  • Data-protection or KVKK officer,

  • Project or service manager.


Depending on the scale of the incident, senior management, corporate communications, human resources, or the customer manager should also be involved.


Personal Data and Security Impact Should Be Assessed Separately

Where the incident involves personal data or information security, it should be assessed not only under the AI policy but also under KVKK, GDPR, information-security rules, and customer contracts.


The following questions should be answered at this stage:

  • Which categories of data were affected?

  • To whom or to which system were the data transferred?

  • Did unauthorised access or disclosure occur?

  • Is there a risk to the rights and freedoms of the individuals concerned?

  • Is notification to the customer, data-protection authority, or another competent authority required?

  • Does the contract contain a specific incident-notification deadline?


Whether a notification obligation exists should be assessed by legal and data-protection experts on the basis of the specific incident.


Not Every AI Error Is a “Serious Incident” within the Meaning of the AI Act

The corporate definition of an incident and the concept of a “serious incident” under the AI Act should be distinguished. An incorrectly prepared email, an inaccurate meeting summary, or an inappropriate visual may constitute an AI incident that should be recorded by the organisation. However, these situations may not, by themselves, meet the AI Act’s definition of a serious incident.


Assessment of a serious incident under the AI Act is particularly important for high-risk artificial intelligence systems. Where there is a possibility of serious harm to health and safety, disruption of critical infrastructure, infringement of fundamental rights, or serious damage to property or the environment, the incident must be separately assessed under the relevant provisions.


Where the deployer of a high-risk AI system considers that the system may present a risk, it should suspend its use and inform the provider or distributor and the relevant market surveillance authority without undue delay. Where a serious incident is identified, notification to the provider, followed by the relevant actors in the supply chain and the market surveillance authority, may become necessary.


The AI Act provides different deadlines for providers’ serious-incident notifications depending on the nature of the incident. As a general rule, notification must be made no later than 15 days after the causal link or reasonable likelihood of a link has been established and after the provider becomes aware of the incident. In the case of a widespread infringement or a serious and irreversible disruption of critical infrastructure, the period may be reduced to two days, and in incidents resulting in death, to ten days under certain conditions. These periods do not apply to every AI use, but only to the relevant serious-incident scenarios regulated under the AI Act.


Evidence and Technical Records Should Be Preserved

One of the most critical but frequently overlooked steps in incident response is the preservation of evidence.


The following records should be retained to the extent possible:

  • The tool and model used,

  • The model or application version,

  • The prompt and user inputs,

  • The output produced by the system,

  • Date and time information,

  • System logs,

  • User and access records,

  • Human-control and approval records,

  • The final content sent to the customer or the public,

  • Changes made after the incident.


Making uncontrolled changes to the system before the root-cause analysis is completed may make it difficult to understand how the incident occurred. Therefore, a balance should be established between technical intervention and the preservation of evidence.


The Communication Plan Should Be Determined According to Role and Impact

Not every incident requires notification to everyone. However, the notification decision should not be arbitrary.


Depending on the specific incident, the parties that may need to be contacted include:

  • The provider of the AI system,

  • The importer or distributor,

  • The customer,

  • Relevant employees or users,

  • The data-protection function,

  • The market surveillance authority,

  • The personal data protection authority,

  • Other competent authorities.


The scope of any communication to the customer should be determined by taking into account the nature of the incident, contractual provisions, data impact, and the corrective actions undertaken.


The Incident Should Not Merely Be Closed; It Should Be Incorporated into the Learning Cycle

Closing an AI incident does not merely mean deleting the incorrect output or sending a corrected response to the customer.


The following work should be completed before closure:

  • Root-cause analysis,

  • Impact assessment,

  • Corrective and preventive actions,

  • Prompt or system-configuration changes,

  • Access and authorisation changes,

  • Policy updates,

  • Reassessment of training needs,

  • Strengthening of the human-control point,

  • Updating the inventory and risk register.


For example, where an employee has entered customer data into a publicly available generative AI tool, merely warning the employee concerned is not sufficient. The approved tools list, data-classification rules, training content, and technical access controls should be reviewed together. A strong AI governance system treats incidents not merely as problems, but as sources of organisational learning that improve the control structure.


References


Comments

Rated 0 out of 5 stars.
No ratings yet
Add a rating
bottom of page