In 2024 AI agents moved from demonstration to commercial use. Unlike question-and-answer products, an agent calls tools, accesses data and executes tasks on the user’s behalf, and can search, place orders, send mail or change a system with real consequences. The compliance question shifts from what content is generated to what authority is used and who answers for the result. The framework formed by the generative AI measures, the Personal Information Protection Law and the Data Security Law still applies, but it has to be unpacked around how agents behave.
How the responsibility structure changes
For a question-and-answer product the core risk is output. For an agent the core risk is the chain of actions. One task may pass through several tools, interfaces and state changes. The user sees only the result; authorisation, data transfer and third-party processing are folded into the background.
Two consequences follow. More parties can be liable: the agent operator, the model provider, the tool provider and the operator of the system being called. And the evidential burden rises: without operation logs, no one can reconstruct who authorised which step, who executed it, and where the data went.
An authorisation chain that can be traced layer by layer
The user’s authorisation of the agent does not replace the agent’s authorisation to the tool provider, nor the tool provider’s notice to data subjects. Three layers must each be established: the user authorises the agent to act; the operator authorises the agent to call a specific tool; the tool provider processes incoming data under its own rules.
Scope should be tied to actions and duration. A general mandate to “handle related matters” is hard to bound in a dispute. Reading and writing, querying and paying, one-off and continuous should each be consented to separately. Sensitive personal information, provision to third parties and cross-border transfer require their own legal basis.
Permission design is compliance design
Data minimisation has an engineering meaning here: grant only the interfaces the task needs, expose only the necessary fields, separate read from write, require human confirmation for irreversible actions, and use a sandbox for high-risk environments.
Credential management matters just as much. Long-lived keys, over-broad service accounts and shared access tokens make user authorisation meaningless. Once a log shows that a call used the operator’s super-user rights, the allocation of responsibility becomes immediately complicated. Short-lived, task-scoped credentials and per-user isolation are cost-effective controls.
Logs, contracts and third-party interfaces
Operation logs should record the task identifier, the tool called, the fields passed, the result returned, the time and the acting party, with a retention period matched to business risk. Logs contain personal information themselves, so access control and redaction cannot be omitted.
Contracts should separate statutory from contractual responsibility. The operator’s duty to the user, the tool provider’s duty to the operator and the called system’s duty to the tool provider belong in the interface agreement. Statutory liability does not disappear because a contract moves it. Third-party terms also need checking: whether sub-licensing is permitted, whether data may be used to train models, and whether call frequency or data location is restricted.
For authorisation and personal-information arrangements, see our data compliance service; for interface terms and liability allocation, see commercial contracts; for credentials and access control, see cybersecurity compliance.
This article is based on China’s Interim Measures for the Management of Generative AI Services, the Personal Information Protection Law, the Data Security Law and public information available in 2024. It is for reference only and does not constitute legal advice.