EU AI Act: Map Applicable Duties to System Requirements

Reviewed and updated October 8, 2026.

Translate applicable EU AI Act duties into system requirements after determining the use case, territory and responsible actors. An application is not automatically high risk because it uses a language model. The legal classification and the organization's role shape which obligations apply.

This article uses official Commission material checked in October 2026. The Commission reports that the AI Omnibus entered into force on July 27, 2026. Its service desk presents consolidated text as of that date. Check the current law, application dates and sector rules with the responsible legal owner before setting a release requirement.

Establish scope before designing controls

Document the intended purpose, users, affected people, decisions influenced and whether the system is placed on the market or deployed internally. Identify provider, deployer and other relevant roles rather than treating “the vendor” as one interchangeable responsibility.

Article 6 sets classification rules concerning covered products or safety components and Annex III uses, with conditions and exceptions. A classification needs the actual intended purpose. Calling a product an assistant or adding a reviewer does not settle that assessment.

Map a duty to observable behavior

For a system to which high-risk requirements apply, Article 12 requires the technical ability to record events automatically for appropriate traceability. Article 26 addresses deployer duties including instructed use, competent human oversight and monitoring.

These duties do not prescribe a universal model gateway, event bus or reviewer model. Specify what evidence and controls are needed for the intended purpose, then choose an implementation that can meet them.

An illustrative reviewed workflow

Consider an applicant-ranking workflow for which the legal owner has determined that the relevant high-risk rules apply. This is a conditional engineering example, not a legal classification of any ALLTIPLY product.

• Traceability: record the released system version, relevant input identifiers, output, review event and final disposition, with an access and retention policy approved for the use.
• Oversight: give a trained, authorized reviewer the information and practical ability to inspect, question and stop the relevant process.
• Monitoring: define which failures trigger suspension, investigation and escalation to the responsible provider or legal owner.
• Change review: reassess when intended purpose, model behavior, input data or decision influence changes.

A log that nobody can interpret does not deliver useful traceability. A nominal approval button without time, information or authority is a weak oversight design. Test the actual review and stop procedures with the people responsible for using them.

Keep engineering evidence and legal approval distinct

Maintain a requirements record linking each applicable duty to an owner, implementation evidence and acceptance check. Mark unresolved applicability or documentation questions explicitly. Technical tests can establish configured behavior; they do not by themselves establish conformity with every legal obligation.

Use AI roadmap and enablement to turn requirements into a bounded technical plan. Request a project review with the intended use and the legal requirements your accountable owner has identified.