Governance and Responsible AI in Practice

Where the text stands: what official EU sources said on 2026-10-22

How to read this: the right-hand column is the date on the source; an amending regulation adopted in July 2026 moved the 2024 dates for the high-risk rules.

• Articles 6, 12 and 14 sit in Chapter III, Sections 1 and 2, so for Annex III systems they follow the 2 December 2027 date. Article 50 is in Chapter IV and follows the general date.
• In the Official Journal text of 2026/1744, Article 1 inserts paragraphs 1a to 1c into Article 6 (safety components) and replaces Article 50(7). It amends none of Article 3(12), Article 6(2) to 6(4), Article 12, Article 14, Article 50(1) to 50(6) or Annex III, and the Publications Office consolidated text of 27.7.2026 (no legal effect) shows them unchanged, so the quotes here are the 2024 wording.
• Check the consolidated text on EUR-Lex and the Commission pages before relying on any date.

Transparency: the Article 50 disclosure

How to read this: the middle column is the Regulation; the right column is a design reading, not a legal conclusion.

The Commission's AI Act page lists "Guidelines on transparency obligations for providers and deployers of certain AI systems"; read them for borderline cases.

Mapping the frameworks to what you produce

How to read this: one registry and one log can answer a NIST outcome and an Article; they are different documents with different status.

NIST says its framework "describes four specific functions" (GOVERN, MAP, MEASURE and MANAGE) and that "Governance is designed to be a cross-cutting function".

ISO/IEC 42001 is not mapped here: ISO's own page returned HTTP 403 on 2026-10-22, so this page makes no claim about its contents.

Change control and incident handling

Figure 5. The life of an AI system in the registry

How to read this: every change to what the card describes returns to Classified, and Suspended is a state a system can be put into without a deployment.

Figure 6. An incident from alert to registry entry

How to read this: the kill switch acts first, and the audit store turns "something went wrong" into a list of affected decisions.

Case files

• A candidate screening assistant and the high-risk classification. In a composite SaaS scenario, an assistant ranks job applicants. Pattern: risk classification in the employment area, with oversight and documentation.
• Credit decisions and the audit trail. In a composite financial-services scenario, a lender's assistant supports credit decisions. Pattern: an audit trail, lineage and explanation records.
• A retail chatbot that must say it is an AI. In a composite retail scenario, a chatbot talks to customers. Pattern: the Article 50 disclosure, kept simple, shown and logged.
• A hospital assistant and automation bias. In a composite healthcare scenario, a procedure-lookup assistant is trusted too much. Pattern: oversight designed against automation bias.

Under the hood: Audit logging that survives an audit

Intuition

An audit log is a flight recorder for decisions: written as the decision happens, readable by someone who was not there, and impossible for the people being audited to edit quietly.

Mechanism

Article 12(1) and 12(2). High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: ... (b) facilitating the post-market monitoring referred to in Article 72; ...

The field list in Article 12(3) opens "For high-risk AI systems referred to in point 1 (a), of Annex III", which is remote biometric identification. For other uses, such as employment or credit, the text above gives purposes and leaves the field list to you and counsel.

Figure 7. One decision writes to the audit store before it is released

How to read this: the decision is released only after the final append is acknowledged, so a decision without a record cannot exist.

1. Append a first entry at request time, with the system and version from the registry.
2. Store ids and hashes of evidence (chunk ids, prompt hash, output hash), not raw personal data.
3. Append the policy result and the human action with the reviewer's id and a reason code.
4. Release the decision after the acknowledgement; fail closed if there is none.
5. Copy the latest chain hash to storage the application team cannot change.

Immutability is a storage property. One documented example: S3 Object Lock "uses a write-once-read-many (WORM) model to store objects", and in compliance mode "a protected object version can't be overwritten or deleted by any user, including the root user in your AWS account" (AWS S3 User Guide, as of 2026-10-22).

Retention pulls two ways. Article 19(1) sets a floor for provider-held logs:

Article 19(1) (extract). ... the logs shall be kept for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law, in particular in Union law on the protection of personal data.

The GDPR points the other way: personal data shall be "limited to what is necessary" and "kept in a form which permits identification of data subjects for no longer than is necessary" (Regulation (EU) 2016/679, Article 5(1)(c) and (e)). Ids and hashes in the audit store, with content in a separate store that has its own retention, serve both. Counsel sets the periods.

What this means for architects

Under the hood: Data lineage

Intuition

Lineage answers "where did this answer come from?" by chaining ids from the answer back to the exact version of the source. The W3C PROV overview (a Working Group Note, 30 April 2013) defines the idea: "Provenance is information about entities, activities, and people involved in producing a piece of data or thing".

Mechanism

Figure 8. Lineage from a source document version to a human decision

How to read this: each arrow is a record that carries an id, so a question can be answered by walking the arrows in either direction.

1. Give every source document a version and keep superseded versions readable.
2. Derive each chunk id from the document id, the version and the chunk text.
3. Record the index version and embedding model with each index entry.
4. Write the chunk ids a retrieval returned into the audit entry for that request.
5. To assess a document change, query for every answer that cited a changed chunk.

Worked number (illustrative): a policy has 1,200 chunks and a revision changes 18. Each answer cites 4 chunks and 12,000 answers were issued last month. If chunks were cited uniformly at random, the chance an answer cited a changed chunk is 1 - C(1182,4) / C(1200,4) = 5.87 percent, so about 705 answers need review. Real traffic is not uniform, which is why you query instead of estimating.

What this means for architects

Under the hood: Model and system cards

Intuition

A card is a nutrition label for a model or system: short, with fixed headings, saying what it is for, how it was measured and where it should not be used.

Mechanism

Mitchell et al. propose model cards for models; Gebru et al. propose datasheets for datasets. The left column is the paper's own headings.

How to read this: the right column is how this course applies each heading to a whole system.

Gebru et al.'s datasheet has seven sections: Motivation, Composition, Collection Process, Preprocessing/cleaning/labeling, Uses, Distribution and Maintenance. Answer them for each dataset you control.

"System card" is not defined in either paper. In this course it means the same idea applied to the whole system, including prompts, retrieval, tools and oversight.

Figure 9. A card as a release artifact

How to read this: the card is built from two sources of truth and checked by the pipeline, so it cannot drift from the system it describes.

Mitchell et al. say the sections "may be tailored depending on the model, context, and stakeholders", and that Training Data "May not be possible to provide in practice".

What this means for architects

Under the hood: Human oversight checkpoints

Intuition

A person can check work before the action, after it by sampling, or when the system asks. Which fits depends on how reversible the action is and how many decisions there are.

Mechanism

Article 14(1). High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.

Article 14(4), extract. ... natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate: ... (b) to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias), in particular for high-risk AI systems used to provide information or recommendations for decisions to be taken by natural persons; ... (d) to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output of the high-risk AI system; (e) to intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state.

Article 14(5) is stricter but limited by its first words: "For high-risk AI systems referred to in point 1(a) of Annex III" (remote biometric identification). There, an identification must be "separately verified and confirmed by at least two natural persons" before any action or decision is taken on it.

Figure 10. Three checkpoint types

How to read this: A gates a single action, B measures the automatic path after the fact, and C lets the system hand a case to a person.

1. Gate before the action when it is hard to reverse or the tier is high.
2. Sample the automatic path so a drifting approve rate shows up as lower agreement.
3. Escalate on low confidence or a rule hit, sized to reviewer capacity.
4. Record reviewer id, time spent, action and reason for every human step.
5. Track the override rate. NIST AI 100-1 says "Data about the frequency and rationale with which humans overrule AI system output in deployed systems may be useful to collect and analyze."

Over-reliance is documented. A systematic review in healthcare (Goddard, Roudsari and Wyatt, JAMIA 2012; abstract read on PubMed) calls automation bias "the tendency to over-rely on automation" and reports that workload and time constraint mediated it; mitigators include training and "updated confidence levels attached to DSS output". It covers clinical decision support, so treat it as a design pointer, not proof for every domain.

How many sampled outputs show a drop in agreement? Set p1 to 0.85 and compare.

With the defaults (one-sided 5 percent, power 80 percent) the widget gives about 149 items, 169 with the continuity correction. Page 8 explains the formula.

What this means for architects

Decision framework

Figure 11. Which governance path does a change take?

How to read this: nothing skips the registry, and the default for an Annex III use is the stricter path until a documented assessment says otherwise.

Comparison of the main options

Failure scenarios to design for

Worked example

Assumptions: 20,000 decisions a day; 6 KB per audit entry; 12 months of retention (chosen for illustration, not a legal period); 8 percent of decisions escalate to a reviewer at 90 seconds each; 2 percent of the others are sampled at 60 seconds each; a reviewer has 6 productive hours a day.

Storage is small; people are the cost. Escalating 4 percent instead of 8 halves the escalation hours to 20, a risk decision the owner records.

Code sample: a tamper-evident audit chain

Each entry stores the hash of the one before it, so changing an old record breaks the chain from that point. This is a sketch of the idea, not a storage design.

import hashlib, json

GENESIS = "0" * 64

def digest(prev, record):
    body = json.dumps(record, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256((prev + body).encode()).hexdigest()

def append(log, record):
    prev = log[-1]["hash"] if log else GENESIS
    log.append({"prev": prev, "record": record, "hash": digest(prev, record)})

def verify(log):
    """Index of the first entry that does not match, or None."""
    prev = GENESIS
    for i, e in enumerate(log):
        if e["prev"] != prev or e["hash"] != digest(prev, e["record"]):
            return i
        prev = e["hash"]
    return None

log = []
append(log, {"decision_id": "d-001", "event": "model_called", "prompt_version": "p-14"})
append(log, {"decision_id": "d-001", "event": "human_decision", "reviewer": "r-207", "action": "approve"})
append(log, {"decision_id": "d-002", "event": "model_called", "prompt_version": "p-14"})
print(verify(log))                      # None: the chain is intact
log[1]["record"]["action"] = "reject"   # someone edits history
print(verify(log))                      # 1: the first broken entry

How to read this: each row's previous hash equals the row above's entry hash; the values come from running the sample.

Common mistakes

• Classifying the model instead of the use. Classify each intended purpose; one model can appear in several registry rows.
• Logging full prompts with personal data forever. Log ids and hashes; keep content in a store with its own retention.
• A person "in the loop" who sees only the AI's answer. Show evidence first, show confidence, and record overrides with a reason.
• Writing the card once. Version it with the system and fail the release gate when it is out of date.
• Copying dates from a summary. Quote the official page and date-stamp it.
• Letting the application team administer the audit log. Use separate credentials.

Try it

Time: 20 to 40 minutes. Pick an assistant you know, or an HR-policy chatbot.

1. Write its registry record with the seven fields from Figure 2's table, including the intended purpose in one sentence.
2. Classify it with Figure 3 and the quoted text. If the answer is "it depends", write down on what and whom you would ask.
3. List the entries one decision should write to an audit store, using Figure 7.
4. Choose one oversight checkpoint type and compute the reviewer hours it needs at your volume.
5. Draft its system card headings.

Done when a colleague can take your registry record and answer the three auditor questions from the real-world problem without asking you.

Key takeaways

• Governance is records produced while the system runs: registry, risk record, card, audit log, monitoring data.
• The EU AI Act's classification attaches to intended use, and Article 6(3) is a documented-assessment exception, not a shortcut.
• On the official sources read on 2026-10-22, Annex III high-risk requirements apply from 2 December 2027 and Article 50 from 2 August 2026; check again.
• Append the audit entry before the decision is released, store ids and hashes, and keep immutability in the storage layer.
• Lineage ids turn "which answers used this document?" into a query.
• Oversight is a capacity and design problem: measure override rate, review time and sampled agreement. Nothing here is legal advice.

Self-check

Further reading

• Regulation (EU) 2024/1689, Official Journal, 12 July 2024, and its amending Regulation (EU) 2026/1744, Official Journal, 24 July 2026. Not legal advice.
• European Commission, AI Act (last update 19 October 2026) and the AI Act Service Desk timeline.
• NIST, AI RMF 1.0, NIST AI 100-1, January 2023.
• Mitchell et al., Model Cards for Model Reporting, FAT* 2019.
• Gebru et al., Datasheets for Datasets, Communications of the ACM, December 2021.

Last verified: 2026-10-22

Next

This page ends Part C. Part D starts with cloud platforms, and that page is not linked here yet.