Standardize before automating

Automation accelerates a stable process, but also increases existing uncertainty and errors.

First map out the current way of working: trigger, input, decisions, exceptions, output, and owner. Standardize what must go well and define where human expertise remains necessary. Then automate only predictable, low-risk steps.

Use three levels: assistance provides a draft, semi-automation performs fixed operations with control, and automatic action is only appropriate for low impact and strong error handling. Full integration via API or customization belongs to Expert.

Process first
Exceptions visible
Assistance versus action
Low impact for autonomy
Owner still needed

This is how you can use this

A support workflow may classify requests and create a draft; reimbursement and contract changes require separate authority.

Try this prompt

Map [process] and classify each step as human, AI concept, semi-automatic, or candidate for automatic action. Justify based on impact, uncertainty, recoverability, and exception.

Your practical assignment

Create a process map and delete any automation for which there is no clear error handling.

8.2

Human approval as a design component

Define who can approve what, with what information and within which time frame.

A simple approval button is not control. Show the proposed action, used source data, changes, risk, rollback option, and deadline. The approver must be authorized and sufficiently informed.

Determine behavior in case of no response: remind, escalate, safely stop, or follow a low-risk standard path. Never carry out a risky action because someone did not respond on time. Log proposal, decision, and execution result proportionally to the risk.

Authorized approver
Decision information
Deadline and escalation
Safe standard
Recoverability

This is how you can use this

An external quote shows changed amounts, conditions, and source data before sending can be approved.

Try this prompt

Design an approval gate for [action]. Provide authority, decision information, risk, deadline, reminder, escalation, safe standard, logging, and rollback method.

Your practical assignment

Design two approval gates: one for low and one for high impact.

8.3

Privacy, rights, and transparency in the workflow

Classify and minimize data before input; do not treat pseudonymization as anonymization.

Use public or fully fictitious data for exercises. Internal information requires policy and necessity; passwords, API keys, identity documents, and complete sensitive files do not belong in a regular prompt. Replacing names with codes is usually pseudonymization: linkage can still exist via other characteristics.

Check rights on source material and output. Document meaningful human choices. Be transparent when people interact directly with AI or rely on synthetic content and legal expectations may be affected. Seek professional advice in concrete cases with high impact.

Classify data
Minimize
Correctly naming pseudonymisation
Check rights
Transparency where needed

This is how you can use this

A customer case for training is made completely fictitious; an internal file is not deemed secure simply by being written by 'Customer X'.

Try this prompt

Create a data and rights register for [workflow]: category, necessity, secure placeholder, retention requirement, access, source rights, transparency, and stop rule. Do not call pseudonymization anonymous.

Your practical assignment

Rework a fictitious risky scenario into minimal, safe training input.

8.4

Measuring value and quality

Measure time, correction work, usability, and risk; prompt volume is not a business value.

Conduct a baseline measurement before the pilot. Record lead time, error or correction rate, quality level, and usage frequency of the existing process. Measure during the pilot using the same definitions. Add a knock-out measure for critical errors or privacy incidents.

A faster concept that requires a lot of rework is not a gain. Therefore, measure total effort until an approved result. Use a small, representative sample and report uncertainty. A positive pilot does not yet prove scalability to other teams or data.

Baseline measurement
Same definitions
Total corrective effort
Critical error separate
Limited conclusion

This is how you can use this

A report workflow measures minutes to approval, number of factual corrections, rubric score, and incidents; not just generation time.

Try this prompt

Design a measurement plan for [pilot] with baseline measurement, numerator, denominator, data source, sample, quality rubric, critical error, measurement period, and scale decision. Avoid unproven productivity claims.

Your practical assignment

Conduct a baseline measurement and three pilot tests and report differences and uncertainty.

8.5

The advanced final project

Demonstrate mastery with a working, tested workflow and a fair implementation decision.

Choose a real, well-defined task without unnecessary sensitive data. Provide result definition, context register, phases, prompts, source verification, test set, example output, human approval, and measurement plan. Also keep a failed test and the correction that followed.

Conclude with a decision: implement, continue limited testing, or stop. Substantiate this with quality, time, risk, maintenance, and transferability. Specify which technical integration or business governance will only be addressed in Expert.

Working workflow
Source and privacy control
Test evidence
Measurement plan
Scale, test, or stop decision

This is how you can use this

Possible projects: research file, document analysis, editorial workflow, team update, or controlled plugin process.

Try this prompt

Help me plan my final project for [task]. Create an evidence checklist for goal, sources, phases, prompts, controls, privacy, tests, human approval, baseline measurement, and implementation decision. Do not execute anything yet.

Your practical assignment

Carry out the project and have another user assess it with the rubric.

Chapter assignment

Bring everything together

Complete a pilot with baseline measurement, workflow, test set, sample result, correction log, privacy and rights register, approval gate, and substantiated input, test, or stop decision.

My notes

Final project

Assessment rubric

Criterion	What do you demonstrate?	control
Result	The end product demonstrably meets a realistic moment of use.	Ready
process	Phases, intermediate products, stop conditions, and responsibilities are explicit.	Ready
Sources	Source facts, assumptions and interpretations remain traceable and separate.	Ready
Test evidence	Normal, difficult, and unsafe cases were tested with predetermined criteria.	Ready
Safety	Privacy, rights, prompt injection, and human approval have been appropriately addressed.	Ready
Improvement	At least one change is better substantiated with comparable evidence.	Ready

From workflow to responsible implementation

Standardize before automating

Human approval as a design component

Privacy, rights, and transparency in the workflow

Measuring value and quality

The advanced final project

Bring everything together

Assessment rubric