Scheiding van taken bij autonome AI is een ontwerpvraag geworden

U moet per workflow expliciet vastleggen welke autonome taken een agent zelfstandig mag uitvoeren, welke onder menselijke goedkeuring vallen, en hoe die verdeling technisch wordt afgedwongen. Dit is niet langer een ontwerpkeuze maar een veiligheids- en verantwoordingsverplichting.

An analysis of 28 August 2026 of separation of duties in agentic AI workflows argues that task separation is now a hard requirement for safety and accountability, not an optional design pattern. The analysis draws on three sources: a governance framework distinguishing what an agent can technically do from what it is permitted to do per workflow, an engineering guide for production agent workflows, and an exploratory note from the French data protection authority CNIL and the Conseil de l'IA et du numérique on agentic AI and personal data. In our assessment, this convergence signals that you can no longer treat autonomous agents as black boxes that simply execute their function; you must now document and enforce task separation as an explicit governance object, and be able to demonstrate that no single agent holds all effective permissions—data access, analysis, approval, and execution—in one hand.

What is the difference between what an agent can do and what it is allowed to do?

The governance framework introduces a critical distinction: Allowed Autonomy Levels (AAL) versus Autonomous Capability Levels (ACL). An agent's technical capacity—what it is capable of—is separate from the autonomy level you assign it per workflow. This separation makes autonomy an explicit, documentable choice. You decide whether an agent may only prepare a task, also analyse it, or execute only after human or policy-based approval. That decision is a governance object that stands independent of the model's raw capability. The agent may be technically capable of many things, but you constrain what it actually does through a formally assigned autonomy level tied to each specific workflow.

How should you structure agent workflows to enforce task separation?

The engineering guide for production workflows identifies nine practices, several of which operationalise task separation at the architecture level:

• Single-tool and single-responsibility agents — each agent performs one discrete function, not multiple tasks in sequence.
• Clean separation between workflow logic and tool servers — the orchestration layer that chains steps together is distinct from the tools that execute them.
• External management of prompts and policies — decision rules and instructions are not embedded in the agent itself but evaluated outside it.
• Partitioned memory per process — agents do not retain shared state across workflows or retain data beyond the scope of a single task.
• Sandboxing and fail-closed defaults — if a control fails, the workflow halts rather than proceeding unsafely.

This architecture limits how far a single error or misuse can propagate through a chain. By ensuring that no one agent holds data access, analysis, approval, and execution together, you reduce the blast radius of compromise or malfunction.

What governance and logging must you put in place?

The CNIL and CIANum note identifies four central risk domains in agentic AI: persistent memory layers, fault cascades, unclear controller and processor roles, and complex multi-service chains. The proposed mitigations converge on traceability and role clarity. You must be able to reconstruct the complete workflow—which personal data was processed, which agents touched it, which external services were involved, and in what sequence. You must also document which agent or human performed each autonomous step, under what authorisation, and with what data. This is not a new legal obligation but a direction: make the division of labour visible and verifiable.

What concrete controls must you be able to demonstrate?

1. Formal autonomy and role model per agent and task — document what each agent may do independently and what requires human or policy oversight.
2. Single-responsibility architecture with separate identities — each agent has one function; orchestration logic is external; policy engines separate decision preparation from decision release.
3. Audit trail showing who or what performed each step — log which agent, which human, which external service, which data, and under which authorisation for every autonomous action.
4. Memory and data partitioning by process — agents do not share state across workflows; sensitive data is isolated per task and not retained beyond its scope.
5. Fail-closed controls and kill switches — if a safety check fails, the workflow stops; users can halt autonomous execution at any point.

What can tooling verify and what remains your professional judgment?

Verification layers can make task separation visible and route decisions through independent checks to surface disagreements and sources. They cannot guarantee correctness, eliminate hallucinations, or prove that every autonomous action is fully reconstructible. The professional judgment—whether the separation is adequate for your risk, whether the autonomy levels match your business need, whether the logging is sufficient for your accountability—remains yours. The studies and the CNIL/CIANum note make clear that task separation in autonomous AI is now an explicit, verifiable design variable. Making that division visible and enforceable is as important as designing it in the first place.