Ethical and Privacy Considerations

Site: Saylor University
Course: [CB DRAFT] PRDV432: No-Code AI Automation
Book: Ethical and Privacy Considerations
Printed by: Guest user
Date: Saturday, 12 September 2026, 10:21 AM

1. Ethical and Privacy Considerations

6.2 Ethical and Privacy Considerations
LOs: [6b]
When you build automations that use AI, you are also making decisions about people, data, and responsibility. That is why ethics and privacy are not separate from automation design; they are part of the design itself.
Building on the workflow logic from Unit 3 and the AI-enhanced tasks from Unit 4, you now need to ask what data the automation uses, who can see it, and what the automation might do with it. Ethical design asks whether the automation is fair, transparent, and appropriate for the task. Privacy design asks whether the automation collects only the data it needs, protects that data, and shares it only with the right people.
A real-world concern appears when an automation processes personal information such as names, contact details, or internal notes. In that case, even a simple workflow can create risk if it sends data to the wrong app, stores it longer than needed, or uses it for a purpose the user did not expect. For this reason, a cautious builder limits access, reduces unnecessary data collection, and checks whether the AI service or platform has rules that affect data use.
Ethical review also helps you notice when an automation may reinforce a bad decision. If a workflow uses AI to draft replies, sort requests, or recommend actions, you should check whether the system gives people a fair chance to review the result and correct it. In practice, this means you do not treat automation as a substitute for judgment in sensitive cases.
As you read the Unit 6.2 material, consider how you would decide whether an automation is safe, fair, and appropriate before you let it handle real user data or support decisions that affect people.
Attribution
Title | Author | Source | License
PRDV000 Unit Readings | Saylor Academy | https://example.com | CC BY 4.0

OUTPUT LICENSE: CC BY 4.0

6.2: Ethical and Privacy Considerations
LOs: [6b]
Automations can save time, but they can also move personal or sensitive data faster than people expect. That makes ethics and privacy important from the start, not as an afterthought. If an automation collects, stores, shares, or transforms data, you need to think about whether that use is appropriate and whether it respects the people involved.
Building on Unit 4, where you used generative AI in workflows, this topic adds a responsibility check. An AI step may produce helpful text or classify content, but you still need to ask whether the data it uses is suitable, whether the output could cause harm, and whether a person should review it before it is sent or stored.
A simple privacy practice is to collect only the data the workflow truly needs. Another is to limit access so that only the right people can see results. You should also document where data enters the automation, where it goes, and where it is stored. This helps you notice risks such as sharing information too broadly or keeping data longer than needed.
For example, a hiring workflow that uses AI to sort applications should not expose private applicant details to people who do not need them. If the workflow sends only the information needed for review to the right reviewer, you reduce unnecessary exposure and make the process easier to govern.
Job-ready Tip: Ask the privacy question early
When you design an automation, ask who can see the data, who can change it, and who can delete it. If you cannot answer those questions clearly, the workflow is not ready to launch.
As you read this unit, think about one automation you would trust with ordinary data but not with sensitive data, and explain what would need to change before you would trust it.
Sources / Further reading
(Authored by Saylor Academy, CC BY 4.0)
Estimated reading time: 4 minutes
6.2: Ethical and Privacy Considerations
This reading supports Unit Learning Outcome 6b.
As you move from building automations to putting them into real use, you need to think about more than whether a workflow works. You also need to ask whether it respects people, protects data, and follows clear rules for who may use it and how.
Why ethics matters in automation
An automation can affect people even when it looks simple on the surface. For example, an AI-assisted workflow that drafts replies to customer messages may save time, but it can also create harm if it sends unfair, inaccurate, or overly confident responses. Ethical practice means you use automation in ways that are honest, fair, and accountable.
Fairness: Do not design automations that treat similar people differently without a clear reason.
Example: A workflow that sorts support requests should not quietly give some users faster help because of language, location, or another personal detail unless the rule is clear and justified.
Best Use: When your automation makes or supports decisions that affect people.
Limitation: A system can still produce unequal outcomes even if the rules seem neutral.
Accountability: A person must remain responsible for the automation.
Example: If an AI tool drafts a message, a team member should review it before it is sent when the message could affect a person’s rights, money, or access.
Best Use: When mistakes could cause real harm.
Limitation: A tool should not become a way to avoid responsibility.
Transparency: People should know when automation is involved if that affects their interaction.
Example: If a chatbot handles first-contact support, the user should not be left thinking they are speaking with a human if that is not true.
Best Use: When trust matters in customer, student, or employee communication.
Limitation: Transparency alone does not make an automation ethical.
Protecting privacy in no-code and AI workflows
Privacy means limiting access to personal data and using it only for a clear purpose. Many automations move information between tools, so it is easy to collect more data than you need.
Data minimization: Collect only the data required for the task.
Example: If a form only needs an email address to send a receipt, do not send full contact profiles into an AI service.
Best Use: When you connect forms, databases, and AI tools.
Limitation: Extra data often increases risk without improving the result.
Access control: Limit who can view, change, or export data.
Example: A workflow that sends employee records to an AI tool should be available only to approved staff.
Best Use: When your automation touches private or sensitive information.
Limitation: Weak permissions can expose data even if the workflow logic is correct.
Retention and deletion: Decide how long your tools keep data and when to remove it.
Example: If a system stores chat logs or prompts, you should know whether those records remain after the task is complete.
Best Use: When a service keeps copies of inputs, outputs, or logs.
Limitation: If you do not check retention settings, data can remain longer than expected.
Governance means setting rules before problems appear
Governance is the set of rules, roles, and review steps that guide how people use automation. It helps teams decide who approves a workflow, who monitors it, and what to do when it fails.
Approval rules: Decide which automations need review before release.
Example: A simple reminder workflow may need less review than an AI workflow that recommends actions for a customer case.
Best Use: When the level of risk changes across tasks.
Limitation: If you review everything the same way, you may slow down low-risk work.
Logging: Keep records of what the automation did.
Example: If an automated message goes wrong, logs can help you find which step caused the problem.
Best Use: When you need to audit or debug behavior.
Limitation: Logs themselves can contain sensitive data, so they also need protection.
Human review: Use a person to check high-stakes output before action.
Example: A workflow that helps prepare a public notice should not publish it without a final human check if the content could affect safety or legal rights.
Best Use: When errors would be costly or difficult to reverse.
Limitation: Human review works only if the reviewer has enough time and context.
Concrete example: an AI customer support workflow
Suppose a company uses an AI tool to draft replies to customer complaints. The tool can speed up response time, but the team still needs rules for privacy and governance. Customer messages may contain account details or personal information, so the team should limit what data the AI receives. The company should also require a human to review replies that mention refunds, account access, or other high-impact issues. This approach keeps the automation helpful while reducing the risk of harm.
As you saw in Unit 5 when you added decision-making to agents, more autonomy can make a workflow more useful and also more risky. The more your automation can decide, the more important it becomes to define boundaries for data use, review, and escalation.
Job-ready Tip: Create a risk checklist
Before you launch an automation, ask three simple questions: What personal data does it use? Who checks the output? What happens if it makes a mistake? If you can answer those questions clearly, you are more likely to build a system that people can trust.
When you evaluate an automation, do you see only the benefit of speed, or do you also see the privacy, fairness, and governance steps needed to make the system safe to use?
Sources / Further reading
(Authored by Saylor Academy, CC BY 4.0)
Estimated reading time: 8 minutes

Callback before_footer in local_aigrade component should be migrated to new hook callback for core\hook\output\before_footer_html_generation
  • line 7225 of /lib/moodlelib.php: call to debugging()
  • line 7292 of /lib/moodlelib.php: call to {closure}()
  • line 71 of /lib/classes/hook/output/before_footer_html_generation.php: call to get_plugins_with_function()
  • line 987 of /lib/classes/output/core_renderer.php: call to core\hook\output\before_footer_html_generation->process_legacy_callbacks()
  • line 97 of /mod/book/tool/print/index.php: call to core\output\core_renderer->footer()