You make responsible use workable with clear roles, training, supplier control, and a rhythm for improvement.
After this chapterYou can design a 90-day pilot and assess supplied results for value, quality, risk, management and adoption. You distinguish a simulated learning assignment from evidence that allows real scaling.
Your progress0 of 48 lessons
8.1
A workable AI policy
Policy should guide daily choices and not just list principles.
Describe allowed and prohibited applications, data categories, approved tools, human responsibility, transparency, source verification, incident reporting, and exceptions.
Link policy to settings, training and an owner. Review it when use cases, suppliers, incidents or rules change.
Allowed
Prohibited
Data
Tools
Review
Incident
How you can use this
An SME policy shows concretely which customer data is allowed in which environment and who approves exceptions.
Try this prompt
Use a completely fictional description of a process, without real case files, personal data or secrets. Write a concise AI policy for [organisation] covering scope, use cases, data, tools, review, transparency, incidents and exceptions.
Your practical exercise
Test the draft policy on ten practical situations.
8.2
Roles and a light governance cycle
Governance scales better with fixed decision points than with a single central blockade.
Use a small forum to review the portfolio, risks, incidents and scaling decisions. The business remains responsible for value; privacy, security, legal and technical specialists act within their authority.
Set intake criteria, decision period, escalation, and registration. Low-risk tests do not require the same process as external customer actions.
Intake
Risk class
Decision maker
Decision deadline
Register
Escalation
How you can use this
A monthly review addresses pilots; critical incidents follow a direct route.
Try this prompt
Design a governance cycle for [organization] with roles, intake, risk classes, consultation, decision rights, register, and urgent escalation.
Your practical exercise
Simulate the intake of a low- and a high-risk use case.
8.3
Training on tasks and mistakes
Adoption requires practice, feedback, and boundaries; not just a general demo.
Train per role on real tasks, allowed data, quality criteria, and errors. Let participants assess and correct output and measure competence through work products.
Provide coaching, example library, and reporting route. Reward stopping or escalating unreliable output; speed pressure must not undermine control.
AI literacy is also an organisational duty under Article 4 of the AI Act. Following the 2026 amendment, providers and deployers take measures supporting the development of AI literacy, adapted to people, tasks and the context of use. There is no mandatory standard course format or general certificate. This course can contribute; add your own work instructions, guidance and exercise evidence. Completion does not automatically demonstrate compliance with the AI Act. Keep a record of which role completed each exercise and what follow-up support is needed.
Role task
Safe data
Errors
Practical evidence
Coaching
Reporting route
How you can use this
Sales practices with incorrect CRM context; finance with divergent spreadsheet definitions.
Try this prompt
Design a role-oriented learning path for [teams] with tasks, risks, exercises, proof of assessment, coaching, and repetition.
Your practical exercise
Design one error exercise per role. Solo, take the roles of Noor, Alex and Sam in turn: who rejects an incorrect delivery promise, who handles missing source information and who decides to pause? Use the supplied fact sheet as the basis for checking. Completion check: each role has recognisable decision rights, a checked response and a reporting route. Note any instruction problems you find; your own role simulation does not demonstrate the competence of real staff.
Source for this lesson
European Commission – AI literacy Current explanation of Article 4: context-based measures, no prescribed certificate and no automatic compliance through one course. Checked: 2026-09-08
8.4
Suppliers, security and continuity
Assess data, access, subprocessors, availability, and exit before dependency.
Inventory which data the supplier receives, contracts and settings, identities, logs and incident reporting. Involve experts in higher risks.
Test export, deletion, fallback, and transition. A strong demo does not compensate for unclear rights or missing continuity.
Determine the GDPR roles for each processing activity. The controller determines the purposes and means; a processor processes personal data on its behalf and according to instructions. In that relationship, Article 28 requires binding processing arrangements, often called a DPA. Check instructions, security, subprocessors, help with rights and incidents, return/deletion and oversight. A paid licence does not replace this assessment. If a party processes data for its own purposes, it is not automatically your processor for that part. If required arrangements are not yet in place, do not start that processing.
Data flow
Contract
Access
Logging
Incident
Exit
Terms in plain language
Subprocessor
A party that processes personal data on behalf of a processor.
SLA
Agreements with a supplier on the level of service.
Sandbox
A separate test environment; check what it actually isolates from real systems.
DPA
Data Processing Agreement: binding arrangements for processing personal data on behalf of a controller, commonly set out in a controller–processor agreement.
How you can use this
A CRM plugin receives access only to a sandbox and limited fields until permissions, logging and deletion have been confirmed.
Try this prompt
Create a vendor questionnaire for [solution] with data, training use, location, subprocessors, access, logs, security, incidents, SLA, export, deletion, and exit.
Your practical exercise
Label each answer as confirmed, contractual, claim, or unknown.
Source for this lesson
OpenAI – API data controls API storage and monitoring; this is not a general retention policy for every ChatGPT account. Checked: 2026-09-07
EDPB – Controller or processor Roles and binding arrangements in a controller–processor relationship; determine the actual relationship for each processing activity. Checked: 2026-09-08
8.5
Driving change with feedback
People adopt a new approach when its usefulness, their role and recovery procedures are clear, and feedback visibly leads to changes.
Identify who saves time, who takes on extra review work and whose expertise changes. Be honest about the consequences and prevent unpaid, hidden work from falling to a few champions.
Measure both usage and quality. Diagnose non-use: poor fit, access, trust, or workload could be the cause. Close the feedback loop with decisions.
In Belgium, also assess information and social consultation requirements in advance. Collective labour agreement CAO 39 concerns new technology with significant collective consequences in private-sector companies usually employing an average of at least 50 workers. Where the conditions apply, information and consultation must take place no later than three months before introduction. Have the workforce calculation, impact thresholds and competent consultation body established; a small fictional course exercise is not automatically such an introduction.
Collective labour agreement CAO 81 concerns monitoring workers’ electronic online communication data and requires purpose limitation, proportionality and transparency. It is not a general authorisation for AI. For monitoring, establish the intended data and assessment and the applicable information procedure. The absence of both a workplace prevention and protection committee (CPBW) and a trade union delegation does not mean no participation: Belgian workplace well-being rules then provide for direct worker participation. Discuss tasks, workload and privacy with the appropriate HR or prevention adviser before the practical trial; record the agreement, owner and date in your pilot dossier.
Stakeholders
Task change
Champion
Work pressure
Feedback
Decision
Terms in plain language
Champion
A colleague who helps others with a new way of working; provide time and support for this too.
CAO
Collective labour agreement in Belgium; the conditions of application differ by agreement.
CPBW
Committee for Prevention and Protection at Work; a Belgian consultation body for workplace well-being.
How you can use this
Reviewers receive extra time and recognition during the pilot instead of the same capacity requirement plus control work.
Try this prompt
Create an adoption plan for [workflow] with stakeholders, benefits and burdens per role, training, support, incentives, feedback and improvement decisions.
Your practical exercise
Extension: interview an enthusiastic and a hesitant user about concrete work experiences. Basic solo route: use two fictional statements: Alex says ‘Drafts are faster, but I cannot finish the source checks within my schedule’; Sam says ‘When information is missing, I am unsure who is allowed to decide’. Separate the signal, missing evidence and possible measure. Completion check: you ask about available review time and decision rights, make one adjustment to the plan and label it as a design based on exercise data.
A pilot has a hypothesis, limited scope, measurement plan, guardrails, and predetermined decision gates.
Organise the pilot into phases: baseline measurement and design, controlled execution, evaluation and decision. Choose representative cases without immediately exposing the entire organisation, and keep incident and change logs.
End with stopping, redesigning, continuing in a limited way, or scaling. Scaling requires proof of value, quality, risk, management, and adoption.
Hypothesis
Scope
Baseline measurement
Guardrails
Decision gates
Evidence for scaling
How you can use this
A quotation pilot runs with two teams and stops after one critical error in the terms.
Try this prompt
Design a 90-day pilot for [use-case] with hypothesis, scope, roles, baseline measurement, evaluations, KPIs, guardrails, incident process, rhythm, and decision criteria.
Your practical exercise
Finish the pilot dossier and assess it from business, user and risk perspectives. With real reviewers, collect their reasons; solo, carry out three separate reading rounds in those fictional roles and label this as self-assessment. Use the final dossier workshop below, update row H8 and check all eight rubric criteria with evidence. Completion check: shortcomings are fixed or identified as blockers, supplied pilot figures remain distinct from your own tests and unknown day 90 results stay open.
Atelier Noor: assess a dossier, repair it and reassess
This fully completed learning assignment is assessed as of day 60. All data, roles and assessments are fictional. Day 90 has not yet been reached, so the scaling decision explicitly remains open. The two shortcomings below are dossier gaps that you must repair. They do not change the given pilot results.
Dossier section
Completed example
Goal and choice
Reduced workload at 300 customer questions per month as a working hypothesis. A: reviewed draft replies. B: autonomous quotations excluded because authority and recovery arrangements are missing. C: newsletter summary still lacks a baseline. Alternative: continue working manually.
Scope and data
Only a fictional product question and an approved product fact sheet. No names, medical explanations, order files or external actions. Alex links drafts to the fictional question outside the chat. This exercise scope says nothing about permission to use real customer data.
Workflow and maintenance
New chat for each case; fixed prompt and source versions. Output: draft or escalation. Alex checks the source, format and correct question matching. Missing information goes to Noor. No integration; H6 examines a possible CRM route only as a simulation.
Storage and supplier
Keep fictional questions, outputs, versions and the decision log in the practice dossier. Internal proposal: retain trial logs for a maximum of 30 days. This proposal gives no guarantee about the service’s retention. Before using real data, confirm the provider, settings, storage, access rights and deletion route separately; current status: not approved.
Measurement plan
Goal → reduced workload; process → full handling time; quality → source support and critical errors; side effects → rework and reviewer workload. Same time definition before and during the trial, including review. Count drafts within each assessed set; report counts and percentages.
Fixed criteria for proceeding
Zero critical errors; at least 95% fully source-supported drafts; an average of no more than 8 minutes; a working manual fallback. Critical means an unauthorised promise or prohibited data. Every test output is assessed by a human.
Evaluation design
Keep D30 and the new D60 cases separate. For each case, record the question, source version, expected result, output, source check, severity and human judgement. Assess normal variation and critical situations. Keep the two unauthorised delivery promises from D30 as regression cases. The H3 set is not part of these cohorts.
Days 1–30
Days 1–15: process, data and practice baseline of 12 minutes. Day 30: 20 cases averaging 7 minutes, with two critical delivery promises. Decision: stop this task, repair the cause and continue manually. The remaining quality percentage is not given.
Day 60
60 different fictional cases: an average of 7 minutes including review; zero critical errors; 58 fully supported; two with a missing non-critical source reference. 58/60 = 96.7%. Manual fallback practised successfully. The measurement thresholds have been met. Limited resumption remains conditional: first repair and verify the missing review and management arrangements below (r6/r7). Also investigate the two references.
Finances
Per month: 300 × (12−7)/60 = 25 hours of potential capacity; at €30/hour, €750. €1,000 upfront and €250 per month; year-1 TCO €4,000. Low/base/high scenarios: 9/7/5 minutes, annual value €5,400/€9,000/€12,600, ROI 35%/125%/215%. At 50% realisation of the base case: €4,500, ROI 12.5%. No demonstrated cash savings. In this exercise scenario, these amounts cover all additional project costs.
Roles — first version
Noor is the business, process and data owner and may pause the work; Alex checks every draft. Review capacity and cover for absence have not been scheduled.
Adoption — first version
Manual fallback has been practised. Training and daily support do not yet have scheduled time or an assigned owner.
Days 61–90
Monitor repeat performance, workload, rework, usable time savings, costs and incidents. Noor collects feedback from both Alex and Sam. On day 90: stop, redesign, continue on a limited basis or scale, according to the criteria and completeness of evidence. A new task, source or model requires reassessment. Outcome: not yet established.
58/60 meets the rule chosen in advance for this exercise set, but does not prove that at least 95% of future replies will be correct. Zero critical errors in 60 cases likewise does not prove that critical errors will no longer occur. Limited resumption still depends on the missing review and management arrangements; keep monitoring new cases. The possible 56/60 in the exercise question is a hypothetical different outcome, not a second tested model group.
Assess all eight existing rubric criteria using evidence from the dossier. Record the reason for each judgement. A positive time score does not compensate for an insufficient review arrangement.
Repair the two specific shortcomings. Use fictional roles if studying alone. Describe available time, responsibility, what happens during absence and how you check that the arrangements work.
Reassess. Keep three claims separate: the quality of the learning assignment, the given fictional pilot outcome and what you have actually demonstrated with your own tests. A model cannot independently confirm that last step.
View the answer and assessment criteria
Assessment and repair — fictional completed example
Rubric criterion
First assessment with dossier evidence
After repair
r1 Strategic fit
Sufficient: the workload goal, task friction and manual alternative are identified.
Sufficient; the question of genuinely usable time remains open.
r2 Value and baseline
Sufficient: the time definition, KPI chain, scenarios and €4,000 TCO can be recalculated.
Sufficient; financial realisation remains a hypothesis.
r3 Data and risk
Sufficient for the fictional exercise scope: minimal fields, no real files, real processing blocked.
Sufficient within that scope; no confirmation about a real provider.
r4 Technical design
Sufficient: manual handover, versions, source rule, escalation and log fields are explicit.
Sufficient; no implemented integration has been demonstrated.
r5 Evaluation
Sufficient as a design: separate cohorts, assessment fields, human source checks and regression cases are recorded.
Sufficient as a design; the given aggregates do not replace your own complete test log.
r6 Human review
Insufficient: no demonstrably scheduled review capacity or substitute reviewer.
Sufficient after the schedule and cover arrangement below.
r7 Adoption and management
Insufficient: training and support are missing from the schedule and ownership arrangements.
Sufficient after the practice session, support agreement and records below.
r8 Decision quality
Sufficient: stop on day 30; on day 60, resumption is conditional on repairing r6/r7; day 90 remains open. Measurement thresholds do not replace review arrangements.
Sufficient: repair management arrangements first, then proceed within the same limited scope.
Repair r6: assuming 20 working days, reserve three hours per day in the fictional schedule for 15 questions, including full manual fallback: 15 × 12 minutes. Alex performs the work; Sam covers absence. If no authorised reviewer is available, the draft remains pending. Noor pauses work if capacity is exceeded or a critical error occurs. This schedule does not prove cash savings.
Repair r7: before the next test, Noor schedules 30 minutes of practice with Alex and Sam: reject an incorrect delivery promise and escalate missing information. Use the known fallback route. Noor handles ordinary support reports within one working day; critical errors mean stopping and reporting immediately.
Reassessment: walk through Alex’s absence and both error cases on paper. Record who takes over, which source demonstrates the error and that nothing is sent. In the fictional completed repair example, Sam rejects the delivery promise and requests additional information when it is missing. The schedule and practice report now support r6 and r7. Perform the same check yourself; missing evidence remains insufficient.
Final assessment of the learning assignment: after these repairs, sufficient as a bounded pilot design. For your own dossier, each criterion must be at least sufficient and supported by appropriate evidence; a critical error blocks release. Remedy shortcomings and reassess. The example figures are supplied practice material: they do not certify a model, learner or production environment. A separate decision still follows on day 90; do not fill in missing results as success.
Worked example
A pilot may also pause temporarily
Fictional practice material; incorrect answers have been created deliberately for this exercise.
All measurements and events are fictional practice data. Atelier Noor plans a 90-day pilot for draft answers, with 300 enquiries a month as a working hypothesis. Every actual sending action remains a separate human decision.
Input
Agreed in advance: days 1–15 map the process, permitted data and baseline. The practice baseline is an average of 12 minutes per enquiry. Decision points occur on day 30 and day 60. Continuing requires: zero critical errors in the assessed set, at least 95% fully source-supported drafts, average handling time including review of at most 8 minutes, and a working fallback to manual handling. Here, critical means an unauthorised promise or inclusion of prohibited data. The employee assesses every test output.
Deliberately flawed practice answer
“Day 30: twenty cases take an average of 7 minutes. That is faster, so scale up. The two unauthorised delivery promises will probably disappear with experience.”
Check
On day 30 there are two critical errors: the time saving does not compensate for the breached boundary. Stop the trial for this task, fix the cause and temporarily continue manually. After tightening source use and escalation, a new set of sixty different fictional cases follows on day 60: an average of 7 minutes, zero critical errors, 58 fully supported drafts and two drafts missing a non-critical source reference. The fallback has been successfully practised. 58/60 is approximately 96.7%. This set meets the agreed thresholds; however, zero observed critical errors does not prove a flawless system.
Improved result
“Decision on day 60: resume on a limited basis within the same task once full human review, sufficient review time and management arrangements are demonstrably in place. The expanded dossier in this chapter shows how missing arrangements block resumption. Investigate the two missing references. Use days 61–90 to monitor repeat performance, workload, rework and usable time savings. On day 90, Noor makes a separate scaling decision based on results, costs, incidents and team feedback. Without that evidence, there is no automatic expansion. A different task, new data source or different model requires an appropriate reassessment.”
Try it yourself
Suppose the new set on day 60 contains only 56 out of 60 fully supported drafts. All other figures remain the same. Calculate the percentage and decide under the rules chosen in advance.
View the model answer
56/60 × 100% is approximately 93.3%, below the 95% threshold. This version therefore does not receive permission to resume the limited trial. Fix the cause and test again on a suitable, different set; do not change the threshold afterwards because the time saving is attractive.
Chapter assignment
Bring everything together
Deliver a 90-day pilot dossier with policy review, governance, training, supplier control, adoption plan, dashboard, and stop-redesign-scale decision.
Maximum 10,000 characters per note.
Progress and notes are stored only in this browser on this device. Do not enter sensitive data. Download your notes regularly. This course sets no automatic expiry date. You can delete the data through your browser’s site-data settings; export anything you wish to keep first. Browser settings or cleanup may erase it earlier. These local notes are not sent to Finaudax.
My assessment
Marking a lesson complete is your own assessment; it does not automatically demonstrate mastery.
Strategic fit
Not yet sufficient: The goal or alternative is missing; a feature is selected as the solution.
Sufficient: Business objective, process problem, and alternative are substantiated.
Strong: The alternative without AI and the decisive uncertainty have also been tested concretely.
Value and baseline measurement
Not yet sufficient: There is no comparable baseline, or costs and benefits are incomplete.
Sufficient: KPI tree, baseline measurement, TCO and scenarios are reproducible.
Strong: Realisable cash value and capacity are separated; scenarios and sensitivity have been recalculated.
Data and risk
Not yet sufficient: Permitted data, rights and recovery have not been defined.
Sufficient: Classification, rights, privacy, reliability, and recovery are managed.
Strong: Overlapping data categories, incorrect linkage and deletion have also been demonstrably tested.
Technical design
Not yet sufficient: There is only a tool list; data flow and failure behaviour are missing.
Sufficient: Context, integrations, permissions, errors and logging are explicit.
Strong: A timeout after execution, duplicate requests and minimum permissions have been checked in a safe trial.
Evaluation
Not yet sufficient: One successful demo serves as evidence; critical cases have not been tested.
Sufficient: The dataset, graders, disqualifying conditions and regression tests are documented.
Strong: New cases, repetitions and human review confirm usability within the defined scope.
Human review
Not yet sufficient: No one demonstrably has the authority or time to review.
Sufficient: Owners, approval, escalation, and stop authority are clear.
Strong: Approvers understand the consequences; rejection, no response and replacement have been practised.
Adoption and management
Not yet sufficient: Training and maintenance are not scheduled or have no owner.
Sufficient: Training, support, monitoring and the runbook can be put into practice.
Strong: Users resolve failure cases, and a rehearsed recovery plan has owners and allocated time.
Decision quality
Not yet sufficient: The decision follows enthusiasm or an average without firm boundaries.
Sufficient: Stopping, redesigning, or scaling follows predetermined criteria.
Strong: The decision holds up under less favourable assumptions and explicitly describes boundaries and review triggers.
