Ethics decisions with operating evidence
SDAIA AI Ethics Principles: Business Guide
Apply SDAIA's seven AI ethics principles through a practical service review covering Arabic performance, human help, explanations and documented trade-offs.
A Saudi business can endorse responsible AI and still make an unclear decision about a particular system. Who receives a worse service when information is incomplete? Can a person challenge an AI-assisted outcome? Does a reviewer have enough time and evidence to intervene? These questions turn ethics from a statement of intention into a design and management discipline.
This guide helps compliance leaders, product owners and procurement teams use SDAIA's principles in practical reviews. Its working examples concern a fictional service-routing assistant. The questions and artifacts below are proposed business methods, not an official SDAIA checklist or a claim of approval.
Read the source and identify the decision
SDAIA's current official description presents its AI ethics principles as a national reference for public and private sectors. The seven labels below follow the accessible September 2023 English edition. For a formal compliance determination, verify the applicable current publication and the organisation's legal, sector and contractual requirements. The worked questions here are practical review aids.
Begin an ethics review with a decision sentence: “The assistant recommends which service queue receives a request; an employee confirms the routing.” Add the people affected, information used, consequence of a wrong recommendation and available remedy. A review of “our chatbot” is too broad to identify who can be disadvantaged or where intervention matters.
Keep the ethics review connected to your business AI governance process. Record who may approve the use, who represents affected users and who can stop it. Ethical concerns should enter the same decision process as cost and delivery, with their own evidence rather than an optimistic sentence in the business case.
Seven principles, seven practical questions
| Principle | Question for the service-routing example | Evidence to request |
|---|---|---|
| Fairness | Do equally urgent requests receive comparable handling across supported language patterns? | Segmented error analysis and review of wrongly deprioritised requests |
| Privacy & Security | Can the task be completed without exposing the entire customer history? | A field-level information map and access tests |
| Humanity | Can someone obtain meaningful human help when the automated route fails? | A tested handover journey and named service owner |
| Social & Environmental Benefits | Does the service improvement justify the resources used and the burden shifted to users? | Before-and-after service measures and a resource-use estimate |
| Reliability & Safety | What happens when an urgent request is unfamiliar or incomplete? | Edge-case results and a conservative fallback route |
| Transparency & Explainability | Can staff explain a routing recommendation using relevant evidence? | Example explanations checked against actual records |
| Accountability & Responsibility | Who corrects a harmful route and decides whether the feature should continue? | Responsibility record, complaint path and decision history |
Use the table to generate work, not to award seven ticks. If the fairness evidence is absent, specify the test and owner. If a fallback exists only in a document, exercise it with a realistic case. A principle can be relevant even when the solution cannot measure it perfectly; explain the limitation and constrain the use accordingly.
Choose a fairness question you can actually investigate
For the fictional assistant, overall routing accuracy hides an important distinction: sending an ordinary query to the wrong team and placing an urgent query in a slow queue have different consequences. Define the errors separately. Then examine whether the test set contains the communication styles and information gaps that the service is expected to handle.
Suppose an illustrative evaluation contains 120 formal Arabic requests and 120 conversational Arabic requests. The system misroutes 6 of the first group and 18 of the second: 5% and 15%. That difference is a reason to investigate, not proof of its cause. Check whether urgency, request type, document quality and labelling differ before concluding that language style alone explains the gap.
Do not collect additional sensitive attributes merely because a dashboard could display them. Decide which comparisons are relevant, proportionate and permissible with the appropriate specialists. Where data is insufficient, record the uncertainty. A defensible response might limit the initial service, increase review of ambiguous requests or gather a better authorised evaluation set.
Make human involvement a real service capability
A human in the workflow is useful only if that person can recognise a problem, access the necessary context and change the outcome. Give reviewers the source request and the available routing options. Show uncertainty in a form they can act on. Do not ask them to approve hundreds of opaque recommendations while measuring them solely on throughput.
Test the escalation journey from the user's perspective. Can a person with a complicated request reach someone who understands it? Does a transferred case retain the original information? Can the receiving employee override the route without seeking permission from the system's builder? These are service-design questions with ethical consequences.
Discuss role changes before launch. The AI change management guide explains how to prepare teams for a changed workflow. In this review, focus on whether staff retain meaningful judgment and whether users face new burdens such as repeating their situation to several channels.
Distinguish an explanation from a plausible story
A fluent explanation is not automatically evidence of why a system reached its output. For routing, ask the assistant to identify the relevant request details and the policy rule used. Check those references against the actual source and policy version. If the explanation cites a rule that was unavailable or invents a fact, its confidence makes the failure worse.
Different audiences need different information. A user may need the next step and a route to challenge the decision. A service reviewer needs the source and rationale. An investigator may need the configuration, test evidence and history. Protect sensitive information while giving each audience enough to perform its role.
Write a short disclosure in the service's own language: what the assistant does, what a person checks, and how to obtain help. Test whether users understand it. Avoid broad statements such as “AI makes this service accurate and unbiased”, which assert a result that the disclosure itself cannot prove.
Resolve ethical trade-offs in a recorded decision
Assume the assistant shortens initial handling time but sends more incomplete requests into a generic queue. The product owner proposes mandatory additional fields. Operations warns that customers with limited documentation may abandon the form. Neither “more automation” nor “more data” settles the issue.
Create a decision note with the alternatives: keep the current form and improve human triage; request one optional clarification; or add mandatory fields. For each, record expected benefit, affected groups, evidence, uncertainty, reversibility and the owner of the consequence. Test the smallest change that can answer the disputed question.
Set an explicit reconsideration condition. For example, if the revised journey increases unresolved cases for a monitored service category, pause expansion and review the design. The threshold should be chosen for the business and consequence, not copied as a universal ethics percentage. Material unresolved risks belong in the risk register; issues beyond delegation follow the board approval route.
Ask suppliers for evidence about your intended use
A supplier's responsible-AI statement may describe its organisation or general model. Your review concerns the service you will operate. Request the product version, relevant limitations, evaluation coverage, configuration options and responsibilities for updates. Separate what the supplier demonstrates from what your organisation must test.
Use vendor due diligence to verify claims and contract responsibilities. If an assessor reviews the deployment, agree what independence and access the review requires through AI audit and assurance. Neither a self-assessment nor a favourable review proves that every future use is acceptable.
Leave the review with a testable commitment
The useful output is a decision record: intended use, affected people, unresolved concern, chosen treatment, evidence owner and review trigger. State what the service is permitted to do now and what additional evidence would support expansion. Keep the approved record connected to incidents and complaints so later decisions benefit from operating experience.
Open for AI's agentic AI consulting can help define the use boundary, map authority and develop an evaluation plan. Bring a redacted service journey, representative examples and one ethical trade-off to discuss a practical AI ethics review. Exact deliverables and review responsibilities are agreed before the engagement.
FAQ
Your questions, answered.
Are SDAIA's AI Ethics Principles the same as legal compliance?
No single ethics checklist establishes all applicable legal compliance. Read the relevant current framework together with the obligations affecting the entity, sector, information and use. Document which requirements apply and obtain an authoritative interpretation where a material decision depends on it. A practical ethics review supports that work without replacing it.
How can we test fairness when Arabic requests vary widely?
Define the consequential errors first, then build a representative authorised test set covering relevant language styles and request types. Compare error patterns while checking for confounding differences such as urgency or document quality. A performance gap is a prompt for investigation; it does not by itself establish the cause or justify collecting sensitive information.
Does a human approval button provide meaningful oversight?
Only when the reviewer can understand the case, inspect evidence, reject the recommendation and obtain support. Check review workload and incentives as well as interface design. Exercise a difficult case to see whether intervention actually changes the outcome. Approval rates alone cannot show whether people are making informed decisions.
What should an AI explanation show to a customer?
Show what happened, the relevant reason that can be supported, the next step and how to request human help or challenge the result. Avoid exposing confidential material or inventing a detailed explanation the system cannot substantiate. Staff and investigators may need additional evidence through controlled channels.
How should a team resolve a conflict between speed and inclusion?
Describe the alternatives and who bears the consequences of each. Test the smallest reversible change that addresses the disagreement, using service outcomes as well as processing time. Record the chosen compromise, unresolved uncertainty and the condition that would trigger reconsideration. The authorised owner should accept the decision explicitly.
What should we retain after an AI ethics review?
Retain the intended use, affected people, reviewed evidence, unresolved concerns, treatment decisions, owners and review triggers. Link the record to the deployed version and subsequent complaints or incidents. This makes the review useful when the product changes and prevents a broad ethical endorsement being reused for a different activity.