Gains:
- Ability to explain ISO 26262 functional security and ISO 21448 (SOTIF) frameworks and their effects on systems containing artificial intelligence
- Ability to manage data privacy, driver data, cybersecurity (ISO/SAE 21434) and ethical risks in the automotive context
- Ability to maintain human responsibility for safety-critical decisions by understanding that AI output is not a substitute for competent engineer approval
You are in the most critical unit of this module. So far we have seen AI as an accelerator from design to manufacturing, from testing to supply chain. But the decisive question in automotive is: will this system harm anyone and who is responsible? This unit covers in plain language the frameworks for using AI responsibly in a safety-critical industry—functional safety, SOTIF, cybersecurity, privacy, and ethics. The core principle remains constant: AI output never replaces competent engineer approval; Security-critical decision and responsibility belongs to the human.
ISO 26262: functional safety
ISO 26262 is the functional safety standard for electrical/electronic systems of road vehicles. Functional safety; It is concerned with ensuring that when a system fails (a sensor breaks, a software fails) it does not lead to a dangerous situation.
At the heart of this standard is ASIL (Automotive Safety Integrity Level). A hazard is evaluated in three dimensions:
- Severity: How bad would it be if it happened? (minor injury or death)
- Exposure: How often does this occur?
- Controllability: How much can the driver control the situation?
These three combined result in a level from ASIL A (lowest) to ASIL D (highest, e.g. braking, steering). As the level increases, development, testing and documentation requirements become stricter.
MAIN
sample system
Requirement intensity
A.
Interior lighting malfunction
low
B.
tail light
medium
C.
Some ADAS functions
high
D.
Brake, steering, airbag
highest
Tip: Knowing the MAIN level of a function tells you how much attention using AI in that function requires. NO decision based on AI output in a function can be accepted without independent security verification.
ISO 21448 (SOTIF): safety of intended function
Classical functional safety (ISO 26262) focuses on the question "what happens if the system fails?" But there is a new problem in artificial intelligence detection systems: even if the system never malfunctions, it may be inadequate. The camera works fine but cannot recognize a snowy slab; The radar is solid, but it ignores a stationary vehicle as a ghost signal. There is no hardware/software failure here; The problem is at the limit of the intended scope of the function.
ISO 21448 - SOTIF (Safety Of The Intended Functionality) addresses exactly this gap: managing risks arising from unrecognized scenarios, detection limits and unforeseen situations, even if the system works as designed. In AI-based ADAS/autonomous driving, SOTIF is as critical as ISO 26262.
Frame
Focus
example
ISO 26262
Risk due to failure
Sensor breaks, signal disappears
ISO 21448 (SOTIF)
Risk of inadequacy/non-recognition
Rugged camera does not recognize snowy slab
ISO/SAE 21434
cyber security
System attack, data manipulation
Caution: AI models are statistical; They cannot guarantee that they will "see every situation correctly". SOTIF aims to narrow down unknown hazardous scenarios in these inherently limited systems and reduce the remaining risk to an acceptable level. “The model is 99.9% accurate” is not a proof of security.
ISO/SAE 21434: cyber security
Connected and software-defined vehicles are vulnerable to cyber attack. A remote attacker can alter the brake command, steal telemetry, or trick the detection model (adversarial attack: making the model misrecognize it by placing a small sticker on a plate). ISO/SAE 21434 is the engineering framework for vehicle cybersecurity. In the context of artificial intelligence, two risks stand out: deceiving the model (adversarial) and poisoning the training data (data poisoning). Security-critical AI systems should be tested against these attacks.
Privacy and personal data
The modern vehicle is a “data center on wheels”: location, driving behavior, audio, even cabin camera. Most of this is personal data and is covered by KVKK (Türkiye) and GDPR (Europe). VIN (chassis number) can identify a vehicle and indirectly its owner. Basic principles:
- Data minimization: Collect only what is needed.
- Purpose limitation: Do not use data for purposes other than the purpose for which it was collected.
- Anonymization/pseudonymization: Remove or encode personally identifying information.
- Explicit consent and transparency: The driver must know what is being collected.
- Secure storage and transfer.
Caution: Sending raw VIN, location history, or driving behavior to a public cloud AI tool can be both a privacy violation and a contractual risk. When working with this data, anonymize it and use an institutional, data-protected environment.
Ethics and engineer responsibility
Artificial intelligence brings with it some ethical risks:
- Bias: If the training data predominates certain conditions (e.g. daytime, light skin, certain regional roads), the model may perform poorly in underrepresented conditions (night, different conditions). This is a vulnerability.
- Overconfidence (automation bias): People blindly trust automation and override their own judgment. If the test engineer stops looking at the raw data just because the AI says “pass,” this is a dangerous trend.
- Loss of responsibility: "The model decided" is not a defence. There should always be a person signing behind the decision.
Mini case studies
Case 1 - SOTIF limit. An automatic emergency braking system passes all laboratory tests, with no malfunctions. In the field, in the low sun, a white truck mistakes its trailer for the sky and brakes late. This is not a malfunction, but a SOTIF vulnerability: the system is intact but the scenario is outside the detection limit. The team adds this scenario to the test library and strengthens radar fusion. Conclusion: "No failure" is not proof of safety; Insufficiency is also a risk.
Case 2 - Biased data. A pedestrian detection model was trained predominantly with daytime data; Night recall is significantly lower. The team balances and retrains night and low light data and reports night scenarios separately. Conclusion: Imbalanced data creates a deadly vulnerability in certain circumstances.
Case 3 - Privacy breach prevention. An analyst is about to paste fleet data into a public AI tool when he notices that the data contains raw VIN and GPS locations. It works in a corporate environment by anonymizing the data (vehicle_01..arac_50 instead of VIN, region code instead of location). Result: A moment of attention prevented a serious KVKK violation.
prompt templates
Template 1 - PRIOR/risk preliminary assessment (draft):
Role: You are a functional safety consultant. Task: Prepares a draft to aid hazard and risk analysis for a function. Context: Function: automatic emergency braking; urban and intercity.Constraint: exact assignment of ASIL; Give a list of questions and points of attention on the dimensions of severity/exposure/controllability; indicate that final assignment rests with the authorized security engineer.Output: Size | evaluation question | attention note table.
Template 2 - SOTIF scenario scan:
Role: You are a SOTIF expert. Task: List scenarios where a detection function might be 'system intact but inadequate'. Context: Camera + radar; low sun, snow, tunnel exit, unusual objects.Output: Scenario | why inadequacy | reduction recommendation.
Template 3 - Privacy control:
Role: You are a data protection (KVKK/GDPR) consultant. Task: Conduct a privacy audit before sharing a data set. Context: Fleet telemetry; The columns contain VIN, GPS, driving score. Constraint: Which fields are personal data, how should they be anonymized, what should I not share at all; sort.Output: Field | risk | recommended transaction chart.
Template 4 - Bias check:
Role: You are an ML safety and fairness auditor. Task: Tell me how to look for risk of bias in a detection model. Context: Pedestrian detection; training data weighted day/city.Output: Condition to check | measurement | risk sign.
Weak prompt / Strong prompt
Weak prompt:
Is this autonomous braking system safe, confirm.
Trying to get AI security clearance is dangerous; Approval belongs to the authorized engineer.
Powerful prompt:
Role: You are a functional safety and SOTIF consultant. Task: List what questions I should ask and what evidence I should collect in the safety assessment of my automatic braking function. Context: AI-based detection; camera+radar; ASIL can be high.Constraint: 'Approve' the system; Provide separate lists of questions and evidence in terms of ISO 26262 (defect) and SOTIF (deficiency); Emphasize that final approval lies with the authorized security engineer.Output: Framework | question | required evidence table.
Common mistakes
- Confusing "no malfunction" with "safe". SOTIF deficiency can kill without malfunctioning.
- Getting AI security clearance. Approval and responsibility lies with the authorized engineer.
- Mistaking model accuracy as proof of security. 99.9% accuracy does not indicate that the remaining risk has been managed.
- Not protecting personal data. VIN/location/driving behavior is within the scope of KVKK/GDPR.
- Ignoring bias and overconfidence. Unbalanced data and blind trust in automation are vulnerabilities.
In summary
- ISO 26262 manages the risk due to failure (with ASIL), while ISO 21448/SOTIF manages the risk of failure without failure; Both are critical in AI detection.
- ISO/SAE 21434 cyber security; adversarial and data poisoning attacks are AI-specific threats.
- Data minimization, purpose limitation and anonymization are mandatory within the scope of KVKK/GDPR; VIN/location is personal data.
- Prejudice, overconfidence and loss of responsibility are the main ethical risks.
- AI output is not a substitute for qualified engineer approval; The security-critical decision and signature always belong to the person.
Application task
Select a safety-related function (e.g. lane keeping). (1) Discuss why the ASIL level of this function may be high/low along the severity/exposure/controllability dimensions. (2) Generate 5 “system solid but inadequate” scenarios with Template 2. (3) Confidentiality audit a relevant dataset with Template 3. (4) Explain why saying “The model confirmed” is not a defense.
checklist
- [ ] I evaluated the ACTUAL dimensions of the function (I left the exact assignment to the authority).
- [ ] I made the distinction between ISO 26262 (malfunction) and SOTIF (insufficiency).
- [ ] I have taken into account the cyber security (adversarial/poisoning) risk.
- [ ] I anonymized and minimized personal data.
- [ ] I checked for risks of bias and overconfidence.
- [ ] I have confirmed that the security clearance is with the qualified engineer.