Fixed rules
Predictable logic with checks for exceptions.
AI assistant
The system proposes; an employee reviews and acts.
AI agent
The system carries out steps within explicit rights and boundaries.
Escalatie
Uncertainty, deviations or higher-impact actions go to an authorised person.
Fallback
The process remains safe if the model, a connection or the data fail.
Assistant, agent and fixed automation rule
Fixed rules execute predefined logic. An AI assistant helps find, structure or propose information while an employee retains the decision and action. An agent can carry out several steps independently within assigned rights and boundaries.
These approaches need different controls. With an assistant, the risk is often blind trust in its proposal. An agent adds permission to act, knock-on effects and speed. Controls should therefore reflect potential impact and reversibility.
Require approval at the right decision point
Not every step needs human approval. Place controls where information is uncertain, an action becomes externally visible, money or rights change, or reversal is difficult. Routine low-risk steps can run automatically when exceptions are reliably detected.
An approval screen should show the relevant context: source data, proposed action, rationale, uncertainty, possible consequences and alternatives. Without it, human oversight becomes a formality.
Sources for this section: European Union · NIST
Logging, traceability and access rights make oversight workable
Record the input and version behind a proposal, who approved it, what action was taken and which exceptions occurred. Logs should support operational follow-up, quality checks and incident investigation without retaining unnecessary personal data.
Limit permissions to the task. A system that drafts an email need not be able to send it. An agent that reads data need not be able to delete them. Separate reading, proposing, approving and executing wherever possible.
Sources for this section: NIST · European Union · Belgian Data Protection Authority
Design exceptions and fallback before launch
Decide what happens when data are missing, confidence is low, instructions conflict, a connection fails or volumes are unexpected. A safe fallback may send the task to an employee, save only a draft or stop the workflow entirely.
Do not test only normal cases. Use representative exceptions and check that employees understand alerts, respond in time and have sufficient authority.
Illustrative example: an agent for customer follow-up
A fictional organisation wants an agent to prepare follow-up emails. It assumes contact details and conversation summaries are reliably available. Initially, the agent only creates drafts; an account manager checks the recipient, content and timing.
After validation, simple reminders may be sent automatically under strict rules. New proposals, sensitive topics and unclear contact status still require approval. Sent messages, source information and exceptions are logged; if the system fails, follow-up returns to a manual process.
What does this mean for your organisation?
Reassess processes where AI output directly leads to communication, a financial action, granting access or a decision about a person. Make the impact, uncertainty, reversibility and responsible role visible at each step.
Do not automate yet if no one owns exceptions, logs are missing or reviewers do not know what to check. Start with one workflow and design for uncertainty, errors, escalation and stopping as well as the normal path.
Sources for this section: European Union · European Union
Frequently asked questions
Must a person approve every AI output?
No. Oversight should be proportionate to risk, impact, uncertainty and reversibility. Low-risk steps can be automated when boundaries and exception handling are reliable.
What makes an approval effective?
The reviewer has relevant context, clear criteria, enough time and authority to change, reject or escalate.
What should logs record?
At a minimum, relevant input, the system or model version, proposed and executed actions, the decision maker, time and exception path — while respecting data minimisation.
Who is responsible for an agent?
Assign a process owner for outcomes and exceptions, plus technical and data owners for operation, access rights and monitoring.
How do you test fallback?
Simulate missing data, low confidence, unavailable connections and unexpected volumes. Check that the workflow stops safely or escalates correctly.
Sources
The sources below support the indicated factual and regulatory passages. The practical decision frameworks are professional recommendations from DSC Solution.
- European Union — Regulation (EU) 2024/1689 — AI Act13 June 2024Used for: risk-based obligations, documentation, oversight and AI literacy.
- NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0)26 January 2023Used for: risk management, governance, and the ongoing assessment and management of AI risks.
- NIST — AI RMF Playbookaccessed 29 August 2026Used for: practical actions for Govern, Map, Measure and Manage.
- European Union — Regulation (EU) 2016/679 — General Data Protection Regulation27 April 2016Used for: principles of lawful processing, data minimisation, accuracy and automated decision-making.
- Belgian Data Protection Authority — Information brochure on artificial intelligence systems and the GDPRDecember 2024Used for: Belgian considerations for AI and personal data.
