The AI Act and AI agents: obligations by role
From intended purpose to the value chain: define the system, classify risk and assign responsibility before selecting controls.
No legal review claimed. References describe the high-risk system regime where applicable. Engineering proposals are technical interpretations, not product certifications.
1. Define the boundary before the control
An agent is not a standalone legal category. Its architecture may combine a model, memory, tools and an executor able to change its environment. First establish which system is put into service, for which purpose and under whose authority. Buying an API does not settle that boundary.
As an engineering method, connect each intended purpose to inputs, outputs, permissions and affected people. Preserve the model version, enabled tools and authorisation configuration. This inventory is a working proposal, not a classification issued by an authority.
2. Provider and deployer
A provider develops, or commissions the development of, a system and markets or puts it into service under its own name. A deployer uses a system under its authority, except for personal non-professional use. An organisation may hold different roles for different systems.
Rebranding a high-risk system, substantially modifying it or changing its intended purpose so it becomes high-risk can bring provider responsibilities under Article 25. An integration change therefore needs a responsibility review alongside its code review.
3. Autonomy does not determine high-risk status
Classification depends on purpose and the conditions in Article 6 and its annexes. A note-writing assistant and a system used to select job candidates need not fall under the same regime. The conditions and exceptions for Annex III require a specific assessment.
Other obligations can still apply outside high-risk classification, including Article 50 transparency requirements and separate sectoral or data protection rules. Record why each obligation was included or excluded rather than treating a product label as the conclusion.
4. From classification to an operating record
For high-risk systems, Article 9 makes risk management an ongoing process. Article 26 sets out use and oversight duties for deployers. A product specification cannot replace that organisational work.
Technical proposal: assign owners for the inventory, authorisations and incident review. Bind each test to a concrete system version and describe exactly what was observed. A single experiment does not establish conformity for every future integration.
5. Where BABYLON fits
BABYLON documents authorisation controls and execution records; CORTEX focuses on memory and NEMESIS on verification. The assurance page publishes observed snapshot states and divergences. That evidence may be partial or stale.
An integration must demonstrate that relevant actions cross its control boundary and that records preserve sufficient context. Installing a component does not certify an intended purpose, replace conformity assessment or automatically transfer legal responsibilities.