3.4 Regulations and Standards for AI

Why AI is governed at all

CT-AI v2.0 learning objective AI-1.1.8 (K2) asks you to explain how regulations and standards affect development and testing of AI-based systems. The core aim of this governance layer is to foster trust and to help realize benefits while mitigating harm. In the ideal picture, following those instruments would support systems that are safe, fair, transparent, sustainable, accountable, ethical, and used responsibly. Testers do not write statutes. Testers often produce the evidence that a claim of responsible use can stand on.

You do not need a global catalog of every national bill. You do need the map: soft-law principles, a landmark risk-based statute in the EU, a lighter-touch pattern elsewhere, technical standards that turn policy language into practices, and sector rules in domains such as healthcare and finance. Official CT-AI exam prices are set by local exam providers and member boards; ISTQB does not publish a single global fee, and this chapter does not invent one.

Soft law: shared compass, not a courtroom exhibit by itself

Internationally, the OECD AI Principles and the United Nations report Governing AI for Humanity are influential soft-law instruments. They foster a shared understanding of responsible AI stewardship and act as a compass for governments and organizations writing their own strategies. They emphasize human-centric AI, ethics, and international cooperation.

Soft law matters to testers because it shows up in internal policies, procurement questionnaires, and responsible-AI checklists long before a hard statute names your product. It is not a substitute for the test results those checklists request. If a principle says a system should be transparent, someone still has to specify what is disclosed, to whom, and how you will test that the disclosure is accurate. A policy PDF without a tested disclosure path is decoration.

The EU AI Act: risk bands, high-risk duties, turnover-based penalties

The EU AI Act is the syllabus's landmark hard-law example. It uses a risk-based approach. Systems are categorized from minimal risk through to unacceptable risk, and the duties scale with the band. Unacceptable-risk practices are barred. Minimal-risk systems face little AI-specific overlay. In between, obligations thicken.

High-risk systems, especially those that affect fundamental rights or safety, face stringent requirements. The syllabus highlights rigorous testing, data governance, and human oversight. That list is a test-strategy outline. Rigorous testing means planned, repeatable evaluation against the risks the system poses, not a single accuracy screenshot. Data governance means provenance, quality, bias investigation, and control of training and monitoring sets. Human oversight means a competent human can intervene in time; that is a testable interaction, not a sentence in a brochure. If the oversight console is unusable, late, or unlogged, the high-risk duty is not met even if the model scores well on a convenient validation set.

Non-compliance can trigger substantial financial penalties based on a percentage of global turnover. Remember the shape of the sanction (turnover-based and serious) rather than inventing a figure the syllabus does not examine as an exam fact. Many countries outside the EU take a more permissive, lighter-touch approach that tries to leave more room for innovation. If you test a product that is sold in the EU and elsewhere, do not assume the lightest regime is the one that defines your evidence pack.

Safety-component uses, for example in aviation, medical devices, or automotive, are the kind of setting treated as high-risk. That classification is why a tester working on a model in a safety wrapper cannot stop at a data-science notebook. The wrapper, the data pipeline, and the human-override path are in scope.

Technical standards: policy language becomes practices

Technical standards from organizations such as ISO and IEEE translate high-level aspirations into specifications and practices. They sit between a statute that says test rigorously and a team that needs a method.

Two references matter at syllabus depth:

• ISO/IEC TR 29119-11 provides guidance on testing AI-based systems and is called out as a critical element in demonstrating regulatory compliance.
• The ISO/IEC 42119 series is being developed to cover various aspects of AI-based system testing.

Standards in this chapter are references, not an invitation to memorize clause trees beyond the syllabus summary. You should know what they are for: turning be responsible into testable practices, and giving organizations a shared vocabulary for evidence. You should not pretend that citing a standard number is the same as performing the tests. If an auditor asks how you used TR 29119-11, the useful answer is the test design you actually ran, not the filename of the PDF.

Sector-specific regulations are also emerging in healthcare and finance, where the harm model differs (clinical safety versus market integrity, privacy, and conduct). A credit model and a radiology model will not share one evidence template even if both use a neural network. Testers in those sectors should expect extra records: clinical evaluation, model risk management, or privacy impact work, depending on the regime that actually applies.

What testers actually produce

Governance without evidence is theatre. For AI-based systems, the compliance file is often the test file:

• Plans that state which risk band you are treating the system as, and why.
• Data-governance records: sources, splits, known gaps, and monitoring.
• Test results for functional performance, robustness, and the human-oversight path.
• Traceability from a requirement or risk to a test and a result.
• Notes on limitations, including non-determinism and the hardware or framework effects from earlier sections of this chapter.

If a regulator, auditor, or customer asks how you know this high-risk system was tested, the honest answer is the documentation of those activities, not a slide that names the OECD principles. Soft law sets direction. The EU AI Act, where it applies, sets duties and sanctions. Standards suggest methods. Testers generate the artifacts that show the methods were used.

Keep this table at summary depth. The K2 task is to explain the effect on development and testing: governance changes what you must test, how rigorously, who must remain in the loop, and which records count as proof. It does not require unpublished fee tables or clause-by-clause ISO recitation.

Governments, industry, academia, and civil society still have to keep talking, because AI capabilities move and texts age. Testers should expect the evidence bar to be reviewed, not frozen. When the bar moves, the regression pack and the risk classification should move with it. Independent OpenExamPrep material on this objective stays at that operational reading: know the instruments well enough to design evidence, and stop where the syllabus summary stops.