Does the EU AI Act apply because an assistant wrote the code?

1. 1. Does the supplied product contain an AI system?

   Apply the Article 3 definition to the delivered behavior. If no, AI-assisted authorship alone does not put that software in an AI-system risk class. Separately assess your organisation's use of the coding assistant.

2. 2. What is the AI system's intended purpose and deployment context?

   Record the function, affected people, decisions and safeguards. Check prohibited practices first. Then assess the Annex I product-safety route or Annex III use cases under Article 6, including the conditions and exceptions. For other AI systems, check duties such as Article 50 transparency.

3. 3. Which role does your organisation perform?

   Identify provider, deployer, importer or distributor responsibilities for this system. An organisation can hold more than one role. Building on another provider's model does not automatically make you that model's provider.

4. 4. Which obligations apply to that role, route and date?

   Use the amended law, including Article 2 scope rules, Article 25 changes of responsibility and transitional provisions. Record the rationale and owner before turning obligations into requirements and evidence requests.

For example, ordinary payroll software written with an assistant differs from a product using AI to rank job applicants. The latter raises an Annex III employment-use question. A chat interface raises its own purpose and transparency questions; it is not automatically high-risk.

The Annex I route concerns an AI system that is itself a regulated product or its safety component, together with the applicable third-party conformity-assessment condition. The July 2026 amendment clarifies the safety-component boundary. Merely adding an AI convenience feature does not establish that route; a failure that can endanger health or safety matters. Annex I Section B products follow sector-specific rules under Article 2(2).

Articles 16 and 26 assign different duties to high-risk providers and deployers. Rebranding, substantial modification or changing an intended purpose can shift responsibility under Article 25. Keep the model provider, system provider and deploying organisation explicit in the evidence record.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026. These dates reflect that adopted amendment, not the original 2024 timetable.

• 2 February 2025: the initial prohibited-practice and AI-literacy provisions began applying.
• 2 August 2025: governance and general-purpose AI model provisions began applying, subject to their transitional rules.
• 2 August 2026: general application date, including Article 50 transparency duties, with the specified exceptions.
• 2 December 2026: the amendment's new prohibitions concerning non-consensual sexual deepfakes and child sexual abuse material apply. This is also the Article 50(2) marking deadline for the specified systems placed on the market before 2 August 2026.
• 2 December 2027: Chapter III Sections 1–3, except Article 6(5), apply to high-risk systems under Article 6(2) and Annex III.
• 2 August 2028: those provisions apply to high-risk systems under Article 6(1) and Annex I, with the relevant sector-specific scope rules.

Article 111 contains further transition rules, including for existing systems. Establish the system's market-entry and modification history before assigning a deadline. The Commission's updated timeline is a useful navigation aid.

For high-risk systems subject to these provisions, a connected engineering record can supply part of the evidence below. The final column identifies the wider system or organisational work. This is a preparation map, not an assertion that Proof implements every collection or assessment step.

The mapping uses the amended provisions, including the changes to Articles 10, 11, 17 and 72. Some Service Desk article pages still reproduce the original June 2024 text; use the amendment and consolidated version when checking a particular obligation.

Illustrative example: an AI-assisted assessment must route an uncertain result to a human reviewer. The responsible team approves the intended behavior and acceptance criteria. The evidence record identifies the implementation, model and evaluation-data versions, the check that ran, its result and any cases outside the tested conditions. A later model or workflow change raises the question of whether that evidence still supports the requirement.

That record helps a reviewer inspect one control. Evaluation coverage, effectiveness of the deployed review process and system-wide risk acceptance still need their own evidence and responsible owners.

Proof today: its graph connects requirements, hazards, code, Changes and verification records, retaining the context for a review and making it available to agents. Development direction: model- and data-aware AI evaluation integrations, operational monitoring connections, release tracking and regulatory profiles. These are not a completed AI Act assessment service.

Bring one AI-related Change and its required evidence to scope a walkthrough. For engineering practice around assistants writing software, see AI4SDLC requirements and testing; that US guidance is a separate source.