A multinational with operations in Toronto, Frankfurt, and Austin opens the same intake form for ten new AI systems on a single Monday morning. By Friday, three of those systems have triggered a Canadian federal Algorithmic Impact Assessment under the Treasury Board Directive on Automated Decision-Making. Two have triggered an EU AI Act Article 27 Fundamental Rights Impact Assessment. All ten have triggered a generic enterprise AI risk assessment for the internal portfolio review. Several have triggered all three, plus a DPIA under GDPR Article 35, plus an NYC LL 144 bias audit, plus a Texas TRAIGA notice. The Responsible AI Officer's job that week is not to write any single artifact. It is to know, for each system, which of the three statutory artifacts the regulators actually expect, in what order, with what content, and how the artifacts coordinate without duplicating work. This lesson is the decision tree.

Three Distinct Artifacts - and Why People Confuse Them

The phrase "AI risk assessment" lands in three different rooms depending on who is in the room. A Canadian federal program manager hears Algorithmic Impact Assessment (AIA): a structured questionnaire mandated by the Treasury Board of Canada's Directive on Automated Decision-Making (2019, updated April 2023), with four impact levels and tier-specific mitigation requirements. An EU AI Act conformity-assessment lead hears Fundamental Rights Impact Assessment (FRIA): Article 27 of Regulation (EU) 2024/1689, a statutory artifact with prescribed content, deployers, timing, and a notification clock under Article 27(3). A NIST AI RMF practitioner hears enterprise AI risk assessment: an internal artifact, framework-aligned but not regulation-anchored, with flexible scope mirroring ISO 31000 plus ISO/IEC 23894:2023.

The three artifacts are not interchangeable. They differ in three operational ways:

• Statutory anchor. Canada AIA - Treasury Board Directive (federal-government deployers only; binding administrative law). FRIA - Article 27 EU AI Act (binding regulation; specified deployer classes). Generic enterprise AI risk assessment: internal, no statutory anchor, framework-aligned to ISO 23894 and NIST AI RMF.
• Scope. AIA applies only to automated decision systems used by Canadian federal departments to make or recommend administrative decisions about clients. FRIA applies only to a narrow class of deployers: public bodies, private operators providing public services, and any deployer of Annex III §5(b) creditworthiness or §5(c) life/health insurance pricing systems. Generic enterprise AI risk assessment applies to everything else the organization has chosen to put through it.
• Content. AIA has a fixed questionnaire (currently 51 risk questions plus 50 mitigation questions) producing a numeric score that maps to Impact Level I-IV. FRIA has prescribed content under Article 27(1)(a)-(f) plus the notification clock under Article 27(3). Generic enterprise AI risk assessment has flexible content drawn from ISO 23894 process steps or NIST AI RMF functions.

The common mistake is to treat the three as substitutes, "we did a generic risk assessment, so FRIA is covered", or to omit the AIA because the deployer "isn't really a regulator" (when the deployer is a federal department running an ADS that affects clients). Both errors are visible to auditors and produce expensive remediation. This lesson is the decision tree that prevents both.

Canada's Algorithmic Impact Assessment - Federal Directive on Automated Decision-Making

The Treasury Board of Canada Secretariat (TBS) issued the Directive on Automated Decision-Making in April 2019, with the AIA as its core compliance instrument. The Directive was updated in April 2023 (third version) and is binding administrative law on federal departments under the Financial Administration Act. The AIA itself is an open-source questionnaire published on Canada.ca, any party can complete it, but the binding obligation falls on federal departments.

What triggers the AIA? Required for any "Automated Decision System" (ADS), "any technology that either assists or replaces the judgment of human decision-makers", used to make or recommend administrative decisions about clients (external parties receiving services from a federal department). Scope includes rules-based logic, statistical methods, machine learning, and generative AI. The April 2023 update extended scope to criminal justice systems (with national-security carve-outs).

The four impact levels. The AIA questionnaire produces a raw score that maps to one of four impact levels:

• Level I (Little impact), reversible and brief impacts on the rights or interests of individuals or communities. Example: a chatbot that surfaces FAQ answers with no decisioning.
• Level II (Moderate impact), likely reversible and short-term impacts. Example: an ADS that triages incoming case files by topic without making any substantive determinations.
• Level III (High impact), difficult to reverse, ongoing impacts. Example: an ADS that recommends approval or denial of benefits applications with human review.
• Level IV (Very high impact), irreversible, perpetual impacts. Example: an ADS that makes or recommends decisions in immigration, asylum, criminal justice, or other matters with severe and lasting consequences.

Tier-specific obligations under Appendix C: peer review (rigor scales with level), employee training, contingency planning, approval (ADM at Level III, Deputy Head at Level IV), plain-language client notice, decision explanation (meaningful at Level III; meaningful plus right-to-challenge at Level IV), source-code release where possible at Levels III/IV, ongoing human monitoring intervention at Level IV, and recourse mechanisms. TBS monitors compliance through annual reporting; the Office of the Auditor General of Canada conducts periodic audits.

Where the AIA fits the global tree. Required for Canadian federal departments deploying ADS for client decisions. Not binding on provincial governments (though Quebec Law 25 and Ontario's proposed Working for Workers Five Act develop analogous mechanisms). Not binding on private-sector Canadian deployers (the proposed federal AIDA under Bill C-27 would extend impact-assessment obligations to private-sector high-impact AI if enacted; remains in committee as of May 2026). The AIA is a public-sector federal artifact with growing provincial and private-sector analogs.

EU AI Act Article 27 FRIA - Statutory Content, Notification, and Timing

Article 27 of Regulation (EU) 2024/1689 establishes the FRIA as a statutory obligation for a specified subset of deployers. The Article is short but operationally dense.

Who must conduct a FRIA? Article 27(1) prescribes three classes of deployer:

• Bodies governed by public law: public-sector deployers at EU, Member State, regional, and local level. The Article reaches every level of government within the Union.
• Private operators providing public services: private organizations contracted by, or operating under, public-service mandates. The most common examples are private hospitals providing public-health services, private contractors operating public-employment services, and private operators of social-assistance programs.
• Deployers of Annex III §5(b) creditworthiness scoring and §5(c) life/health insurance risk-assessment and pricing systems, regardless of whether the deployer is public or private. This sweeps in every EU bank doing credit scoring and every EU life/health insurer doing risk-based pricing using a high-risk AI system.

Article 27(1) further requires that the FRIA be performed before deploying a high-risk Annex III AI system (with the public-bodies and private-operators-providing-public-services scope triggering FRIA for any Annex III deployment, not only §5(b)/§5(c)).

Mandatory content under Article 27(1)(a)-(f). The FRIA must contain:

1. 27(1)(a), A description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose.
2. 27(1)(b): A description of the period of time within which, and the frequency with which, each high-risk AI system is intended to be used.
3. 27(1)(c), The categories of natural persons and groups likely to be affected by its use in the specific context.
4. 27(1)(d), The specific risks of harm likely to have an impact on the categories of natural persons or groups of persons identified pursuant to (c), taking into account the information given by the provider pursuant to Article 13.
5. 27(1)(e), A description of the implementation of human-oversight measures, according to the instructions for use.
6. 27(1)(f), The measures to be taken in the case of the materialization of those risks, including the arrangements for internal governance and complaint mechanisms.

Notification under Article 27(3). Once the FRIA is performed, the deployer must notify the market surveillance authority of the results, "submitting the filled-out template referred to in paragraph 5." The Commission, via the AI Office, will issue an automated tool under Article 27(5). For similar use cases, the deployer may rely on a previously conducted FRIA, updating where necessary.

Coordination with DPIA under Article 27(4). Where Article 27 obligations are already met through a DPIA under GDPR Article 35 or Article 27 of Directive (EU) 2016/680 (Law Enforcement Directive), the FRIA "shall complement" the DPIA. A combined DPIA/FRIA template is prevailing 2026 practice for EU deployers of high-risk AI processing personal data.

Timing under Omnibus VII. Article 27 applies on the Annex III deployment tracks. Under the May 7, 2026 Omnibus VII political agreement, the stand-alone Annex III deployment date moved to Dec 2, 2027, with §5(b) creditworthiness and §5(c) life/health insurance pricing on a separate Aug 2, 2026 track tied to credit/insurance sectoral obligations. FRIA capability development takes 9-12 months per high-risk system and the late-2027 notified-body capacity wall will be acute.

Generic Enterprise AI Risk Assessment - Internal Artifact, Framework-Aligned

Outside the AIA and FRIA mandates, the third artifact is the generic enterprise AI risk assessment, an internal artifact conducted on every AI system regardless of regulatory status. No statutory anchor, no prescribed content. Framework-aligned, typically to ISO/IEC 23894:2023 ("Guidance on risk management") and NIST AI RMF 1.0, with structural alignment to ISO 31000.

Standard structure of a generic enterprise AI risk assessment. Six sections, mirroring ISO 23894 process steps:

1. System description. Name, version, vendor, deployer business unit, intended use, deployment context, in-scope user populations, integration points.
2. Risk identification. Brainstormed inventory of potential harms: performance, bias, privacy, security, intellectual property, third-party dependency, model drift, output explainability, downstream agent autonomy. Often anchored to NIST AI 600-1 GenAI Profile twelve risks for generative systems.
3. Risk analysis. Likelihood × consequence scoring per risk, with severity bands defined by the organization (e.g., 1-5 likelihood, 1-5 consequence, 25-cell heat map).
4. Risk evaluation. Comparison against risk-appetite thresholds set by the AI Governance Committee or the board.
5. Risk treatment. Mitigation actions per risk, owner, due date, residual-risk score after treatment.
6. Monitoring and review. Cadence for re-assessment (often quarterly for high-tier systems, annually for lower-tier), trigger events that force re-assessment (vendor model update, scope expansion, fine-tuning, deployment context change, incident).

How it complements the AIA and FRIA. The generic assessment is broader and lower-stakes: it covers risks the statutory artifacts don't (IP leakage, vendor lock-in, model-drift cost, internal reputational risk), runs on every system in the inventory, and is the artifact the AI Governance Committee actually reads at monthly portfolio review, the AIA and FRIA are exhibits attached for the regulated subset.

Alignment with ISO/IEC 23894:2023. The ISO/IEC JTC 1/SC 42 standard providing AI risk-management guidance, structured around ISO 31000. The template should be ISO 23894-aligned so one artifact serves both purposes (lesson 042 details the process).

Alignment with NIST AI RMF. The Map function, especially Map 5 ("Impacts to individuals, groups, communities, organizations, and society are characterized"), asks the same questions. Profile work (lesson 043) hooks into the same artifact.

The Decision Tree Applied to Ten Representative Systems

The Responsible AI Officer's job on Monday morning is to walk every new system in the intake queue through a five-question decision tree. Answer the questions in order:

1. Deployer type. Is the deployer a Canadian federal department? An EU public body? A private operator providing public services in the EU? A purely private organization?
2. Jurisdiction of deployment. Canada? EU? US? Multiple? (Article 2(1) extraterritorial scope of the EU AI Act applies wherever outputs are used in the Union.)
3. Annex III category. Does the system fall into one of Annex III's eight high-risk categories, and if so, which?
4. Downstream-affected-persons criteria. Do natural persons face individual decisions or substantive impacts from the system's outputs?
5. Article 25 transfer status. Did the deployer fine-tune, trademark, or substantially modify a GPAI model such that Article 25(1) shifted provider obligations to the deployer?

Apply the tree to ten representative systems and the artifact obligations shake out cleanly:

System 1 - Canadian federal department deploying decision-support AI for benefits processing

Deployer type: Canadian federal department. Jurisdiction: Canada (no EU outputs). Annex III: Not in EU scope (no EU outputs). Affected persons: Yes, clients applying for benefits. Article 25: N/A.

Required artifacts: Canada AIA mandatory under the Treasury Board Directive on Automated Decision-Making. Generic enterprise AI risk assessment recommended for internal portfolio review. No FRIA required (no EU deployment). If the system later begins serving Canadian clients living in the EU or accepting EU residents' applications, the FRIA obligation would attach on the Annex III §5(a) public-assistance track.

System 2 - Private-sector EU bank deploying §5(b) credit-scoring AI

Deployer type: Private EU bank. Jurisdiction: EU. Annex III: §5(b) creditworthiness scoring, high-risk. Affected persons: Yes, credit applicants. Article 25: Depends on whether bank fine-tuned upstream GPAI model.

Required artifacts: Article 27 FRIA, mandatory under §5(b) deployer scope on the Aug 2, 2026 sectoral track. GDPR Article 35 DPIA, mandatory (personal data + automated decision-making affecting the data subject). Combined DPIA/FRIA under Article 27(4). Generic enterprise risk assessment. No Canada AIA. ECB SREP, EBA model-risk-management guidance, and national supervisor expectations apply on top.

System 3 - Public-sector EU hospital deploying Annex III §5(a) public-assistance triage

Deployer type: Public-sector body (state hospital). Jurisdiction: EU. Annex III: §5(a) public-assistance benefits and services, high-risk. Affected persons: Yes, patients. Article 25: N/A.

Required artifacts: Article 27 FRIA, mandatory under public-body scope. DPIA under GDPR Article 35 (health data = Article 9 special category). Combined DPIA/FRIA. Generic enterprise risk assessment. MDR overlay possible if system qualifies as a medical device (Annex I). No Canada AIA.

System 4 - Private-sector US-only marketing AI (no Annex III hit, no EU outputs)

Deployer type: Private US company. Jurisdiction: US only (no EU outputs, no Canadian government use). Annex III: Not applicable (no EU scope, no Annex III category even if EU scope applied). Affected persons: Diffuse, marketing audiences. Article 25: N/A.

Required artifacts: Generic enterprise risk assessment only. No FRIA. No Canada AIA. State-level overlays may apply (CCPA, Colorado SB 24-205 currently stayed, Texas TRAIGA HB 149 if Texas-domiciled audience). Lightest of the three regimes.

System 5 - Multinational HR resume-ranker (Annex III §4) deployed in EU + NYC + Texas

Deployer type: Private multinational. Jurisdiction: EU + US (multiple states). Annex III: §4 employment, high-risk in EU. Affected persons: Yes, job applicants. Article 25: Possible if HR team fine-tuned a GPAI model on internal candidate-evaluation data.

Required artifacts: EU AI Act Article 27 FRIA on the Dec 2, 2027 stand-alone Annex III track (the deployer is private, not a public body; the FRIA obligation attaches because §4 employment is in scope for the broader Annex III deployer-FRIA track for public bodies and private operators providing public services, for purely private deployers of Annex III §4, the FRIA is recommended as best practice but the statutory FRIA is not automatically required unless the deployer is a public body or provides public services; the §5(b)/§5(c) FRIA mandate is the universal-deployer track). DPIA under GDPR Article 35. Generic enterprise risk assessment. NYC LL 144 independent bias audit (annual, by independent third party, four-fifths rule analysis, 10-business-day candidate notice). Texas TRAIGA HB 149 intentional-discrimination analysis. EEOC Title VII analysis for federal-employment-discrimination overlay. Canada AIA not required (not Canadian government). Six distinct artifacts on the same system, coordination through a single intake document is essential.

System 6 - Canadian government deploying the same hiring AI

Deployer type: Canadian federal department. Jurisdiction: Canada (and EU if outputs touch EU residents). Annex III: §4 employment in EU if outputs used there. Affected persons: Job applicants. Article 25: N/A.

Required artifacts: Canada AIA mandatory under the Treasury Board Directive (Level III likely for hiring-decision support; Level IV if it makes the final determination). FRIA required if EU outputs (public-body scope automatically triggers FRIA for any Annex III deployment). DPIA under GDPR if EU outputs. Provincial human-rights commission analysis (depending on Canadian deployment province, e.g., Ontario Human Rights Code, Quebec Charter of Human Rights). Generic enterprise risk assessment for internal review. Possibly four to five regulatory artifacts on a single system.

System 7 - Annex III §1 facility biometric ID (employee access)

Deployer type: Private operator (or public, depending). Jurisdiction: EU. Annex III: §1 biometrics (remote biometric ID excluded under Article 5(1)(h) for real-time public-space law-enforcement use; on-premises employee-access is different). Affected persons: Employees and visitors. Article 25: N/A typically.

Required artifacts: Article 27 FRIA if public body or private operator providing public services (private-sector employee-access on private property is generally not "providing public services", the FRIA is recommended but not statutorily required unless the deployer is a public body). DPIA under GDPR Article 35, mandatory (biometric data is GDPR Article 9 special category). Annex VII Module H notified-body conformity assessment (Article 43 for biometric Annex III §1 systems triggers Module H conformity-assessment procedure rather than the Module A internal-control procedure for most Annex III categories). Generic enterprise risk assessment. National-law variations on biometric processing in the workplace (France CNIL, Germany BDSG).

System 8 - GPAI base model used internally as coding assistant (no Annex III, no public-service deployment)

Deployer type: Private. Jurisdiction: EU (engineering team in EU). Annex III: Not applicable (developer IDE plug-in, no high-risk use case). Affected persons: Internal engineers only. Article 25: No fine-tuning beyond simple prompt engineering.

Required artifacts: Generic enterprise AI risk assessment. Article 4 AI literacy program for the engineering organization. No FRIA. No Canada AIA. No DPIA (no personal data of natural persons being processed beyond ordinary employment-relationship use). The lightest stack of the EU set.

System 9 - Education proctoring tool (Annex III §3, private edtech)

Deployer type: Private edtech (selling to universities). Jurisdiction: EU. Annex III: §3 education, high-risk. Affected persons: Students. Article 25: Depends on model architecture.

Required artifacts: Article 27 FRIA on the Dec 2, 2027 stand-alone Annex III track. DPIA under GDPR Article 35 (student personal data, possibly Article 9 special category if biometric/emotion components). Generic enterprise risk assessment. The university client (as deployer) inherits the FRIA obligation if it is a public university (public body), most EU universities are public bodies. The edtech provider supplies the FRIA inputs under Article 13. Coordination between provider and deployer is essential.

System 10 - Internal Llama 3.1-405B fine-tuned for IT-helpdesk agent

Deployer type: Private. Jurisdiction: EU. Annex III: Not applicable (internal IT helpdesk, no high-risk use case). Affected persons: Internal employees. Article 25(1)(b): The fine-tuning triggers Article 16 provider obligations on the deployer, the organization becomes a provider of a modified GPAI system. The fine-tune may not trigger the Article 51 systemic-risk threshold (Llama 3.1-405B is below the systemic-risk training-compute threshold under Annex XIII), but the fine-tune itself triggers Article 25(1)(b).

Required artifacts: Generic enterprise risk assessment. Article 26 deployer obligations on the underlying use. Article 16 provider obligations on the fine-tuned variant (technical documentation; instructions for downstream use even if internal; record-keeping; Article 53 GPAI provider documentation since the fine-tuned variant is a GPAI model in its own right). Non-signatory diligence on Meta's Code of Practice posture (Meta has been a notable non-signatory). No FRIA (no Annex III hit). No Canada AIA (not Canadian government). No DPIA unless the helpdesk processes personal data of natural persons.

Multi-Jurisdiction Scenario - Running All Three Assessment Types in One Portfolio

Apply the decision tree across a multinational portfolio of 50 AI systems and the artifact map gets specific. A representative portfolio has:

• ~10 systems requiring no statutory assessment (purely US-domiciled, no Annex III hit), generic enterprise risk assessment only.
• ~20 systems requiring a generic enterprise risk assessment plus an Article 50 transparency disclosure but no FRIA, limited-tier EU exposure plus internal risk artifact.
• ~12 systems requiring an Article 27 FRIA: typically the HR systems (Annex III §4 with public-body or public-service connection), credit/insurance systems (§5(b)/§5(c) universal), and a handful of biometric/education/critical-infrastructure systems.
• ~3 systems requiring a Canada AIA: typically Canadian-federal-department deployments of decision-support AI for benefits, immigration, criminal justice, or other client-facing administrative determinations.
• ~5 systems requiring a combined DPIA/FRIA artifact under Article 27(4), typically high-risk AI processing personal data at scale.

The coordination challenge is not writing any single artifact. It is making the artifacts coordinate. The combined DPIA/FRIA template is one mechanism; a single intake document feeding the appropriate artifact paths is another; an AI Governance Committee monthly review reading the generic risk assessment with FRIA/AIA/DPIA exhibits attached is a third. L4/L5 lessons revisit the operating model in depth.

Coordination with the DPIA - Article 35 GDPR and Article 27(4) AI Act

GDPR Article 35 has required a DPIA since May 2018 for processing "likely to result in a high risk to the rights and freedoms of natural persons", explicitly including profiling-based automated decision-making. Nearly every Annex III high-risk AI system processing personal data triggers an Article 35 DPIA in parallel with the Article 27 FRIA.

Article 27(4) of the AI Act provides the coordination rule: where Article 27 obligations are already met through a DPIA under GDPR Article 35 or LED Article 27, the FRIA "shall complement" the DPIA. The operational reading: produce a single combined artifact with cross-reference columns mapping each Article 27(1)(a)-(f) item to the corresponding DPIA section under Article 35(7)(a)-(d).

Combined DPIA/FRIA template, seven sections: (1) system description, Art. 35(7)(a) + 27(1)(a); (2) processing operations and period/frequency of use, Art. 35(7)(a) + 27(1)(b); (3) categories of data subjects and affected persons, Art. 35(7)(c) + 27(1)(c); (4) specific risks combining privacy and fundamental rights, Art. 35(7)(c) + 27(1)(d), this is where the two artifacts most diverge and benefit from joint analysis (DPIA risks center on CIA + data-subject rights; FRIA risks center on non-discrimination, human dignity, freedom of expression, fair-trial rights, and the full Charter catalog); (5) human-oversight measures, Art. 35(7)(d) + 27(1)(e); (6) risk-mitigation and complaint mechanisms, Art. 35(7)(d) + 27(1)(f); (7) notification, DPO and (where required under Art. 36) supervisory authority for DPIA, market surveillance authority under 27(3) for FRIA.

A combined artifact reduces effort by 40-60% versus two separate documents and lowers the audit-evidence burden because the cross-walk is explicit. EDPB and the AI Office are expected to publish a model combined DPIA/FRIA template in 2026; until then, prudent deployers build it internally.

Coordination with ISO/IEC 23894 and NIST AI RMF

The generic enterprise AI risk assessment is the bridge artifact connecting the regulatory artifacts (FRIA, AIA, DPIA) to the broader risk-management framework. ISO/IEC 23894:2023 and NIST AI RMF 1.0 are the two principal alignment standards.

ISO 23894 alignment. ISO 23894 applies the ISO 31000 process to AI, covering risk identification (clause 6.4.2), analysis (6.4.3), evaluation (6.4.4), treatment (6.5), monitoring (6.6), and reporting (6.7). The generic assessment maps section-to-clause: system description supports scope-setting in 6.3; identification = 6.4.2; analysis = 6.4.3; evaluation = 6.4.4; treatment = 6.5; monitoring = 6.6. One artifact serves both regulatory exhibit and ISO 23894 evidence roles.

NIST AI RMF alignment. Map 5 ("Impacts to individuals, groups, communities, organizations, and society are characterized") asks the same questions as Article 27(1)(c)-(d) and the AIA impact-level scoring. The generic assessment's identification and analysis sections double as NIST AI RMF Map evidence, one artifact, three frameworks.

Audit-time cross-walk. An ISO 42001 stage-2 audit, NIST AI RMF maturity assessment, SOC 2 AI-controls attestation, EU AI Act notified-body engagement, and Canada TBS annual review each ask for the same underlying analysis. Build to the ISO 23894 spine, attach FRIA/AIA/DPIA as exhibits, cross-walk reduces audit effort by 30-40%.

Cross-Walks - Treasury Board Directive, Article 27, GDPR, ISO 42001, NIST, SR 11-7

For the Responsible AI Officer holding the decision-tree memo, the cross-walks worth memorizing:

• Canada Directive on Automated Decision-Making (2019, updated April 2023), Treasury Board Secretariat; binding on federal departments; AIA questionnaire mapped to four impact levels with tier-specific mitigation requirements under Appendix C; AIDA private-sector extension pending under C-27.
• EU AI Act Article 27: statutory FRIA for public bodies, private operators providing public services, and §5(b)/§5(c) deployers; content under 27(1)(a)-(f); notification clock under 27(3); DPIA coordination under 27(4); template tool to be issued by the Commission under 27(5).
• GDPR Article 35, DPIA for high-risk processing; content under 35(7)(a)-(d); DPO consultation; Article 36 prior consultation with supervisory authority where residual risk remains high; coordination with AI Act FRIA under Article 27(4).
• ISO/IEC 42001:2023 Annex A control A.5 ("Impact assessment"), AIMS requirement to define and document AI system impact assessment; A.5.1 governance, A.5.2 impact assessment process, A.5.3 documenting impacts. Annex A control A.6.1.1 ("Considerations for AI system impact and risk") connects impact assessment to risk management.
• NIST AI RMF 1.0 Map 5: "Impacts to individuals, groups, communities, organizations, and society are characterized." Plus Map 1.1 ("Context is established and understood") and Map 5.1 ("Likelihood and magnitude of each identified impact are determined").
• SR 11-7 (Fed Reserve SR Letter 11-7 / OCC Bulletin 2011-12): supervisory guidance on model risk management; for AI-enabled banking models the SR 11-7 model-validation, independent-review, and ongoing-monitoring requirements apply on top of the FRIA. Lessons 067-069 take SR 11-7 application to LLMs and agents in detail.
• NYC Local Law 144: for Annex III §4 employment systems deployed in NYC: independent bias audit, four-fifths rule analysis, 10-business-day candidate notice. Lesson 015 covers NYC LL 144 enforcement state.
• EBA Guidelines on internal governance / EBA Discussion Paper on AI in banking, sector overlay for §5(b) credit-scoring deployers in EU banks.

Six Common Mistakes - And How to Catch Them

Mistake 1 - Treating the three artifacts as substitutes

"We did a risk assessment, so FRIA is covered." This argument fails on two grounds. First, the generic enterprise risk assessment lacks the prescribed content of Article 27(1)(a)-(f), so it cannot satisfy the statutory FRIA obligation. Second, the FRIA has a notification clock under Article 27(3) and a market-surveillance-authority deliverable that the generic risk assessment does not have. The decision-tree memo should make the artifact obligations explicit per system, naming the statutory anchor and content requirements for each.

Mistake 2 - Conducting a FRIA without a DPIA where personal data is processed

Article 27 FRIA and GDPR Article 35 DPIA are coordinated under Article 27(4), but neither subsumes the other. A FRIA without a DPIA misses the data-subject-rights, lawful-basis, and necessity-and-proportionality analysis required by Article 35(7)(b)-(c). A DPIA without a FRIA misses the fundamental-rights catalog beyond data protection: non-discrimination, dignity, freedom of expression, fair-trial rights. The combined DPIA/FRIA template avoids both errors.

Mistake 3 - Missing the Canada AIA for Canadian federal-government deployments

A common misperception in EU-headquartered organizations is that the Canada AIA is "best practice but not binding." In fact, the Treasury Board Directive on Automated Decision-Making is binding administrative law on federal departments, with monitoring by TBS and audit by the Office of the Auditor General. A Canadian federal department deploying an ADS without an AIA is in breach of the Directive. For multinational SaaS vendors selling to Canadian federal departments, supporting the deployer's AIA process is increasingly a procurement-evaluation criterion.

Mistake 4 - Missing the §5(b)/§5(c) Aug 2, 2026 FRIA-required deployment track

Most EU AI Act timeline conversations focus on the Dec 2, 2027 stand-alone Annex III deployment date (post-Omnibus VII). But the §5(b) creditworthiness scoring and §5(c) life/health insurance risk-assessment and pricing categories have a separate FRIA-deployer track tied to the credit/insurance sectoral obligations. EU banks doing credit scoring and EU insurers doing life/health pricing should not be relying on the Dec 2, 2027 timeline, the §5(b)/§5(c) deployer FRIA obligation attaches on the Aug 2, 2026 track. Programs that have not begun FRIA capability development for §5(b)/§5(c) deployments by mid-2026 are behind schedule.

Mistake 5 - Weak deployer-type analysis (public body vs. private operator providing public services vs. private)

The Article 27(1) deployer-type definitions are the most contested aspect of FRIA scoping in 2026. "Bodies governed by public law" is clear at the core (federal/state/regional/local government) but the periphery includes public universities, public hospitals, certain regulated utilities, and certain transport authorities. "Private operators providing public services" is the harder category, a private hospital under public-health-system contract is in scope; a private hospital with only private-pay patients may not be; a private contractor running a public-employment service is in scope. Member State implementing law and AI Office guidance through 2026-2027 will clarify the periphery. Programs should err toward the broader interpretation and document the deployer-type analysis explicitly in the FRIA scoping memo. Lesson 044 dives deep into FRIA scoping in the post-Omnibus environment.

Mistake 6 - Treating the decision tree as static

An AI system that is "FRIA not required" today becomes "FRIA required" when the deployer wins a public-sector contract, when the system is fine-tuned and re-deployed in a new context, when a vendor adds an Annex III §5(b) feature, when the system's outputs begin to flow to the EU. The decision-tree memo is a living artifact. Quarterly review plus triggered updates on deployer-type change, vendor model change, scope expansion, fine-tuning, and new deployment context, the same trigger events as the tiering memo from lesson 002. Programs that fix the decision tree once at intake and never revisit it produce surprises 12-18 months later when the regulator notices first.

Key Takeaways

• Three distinct artifacts. Canada Algorithmic Impact Assessment (Treasury Board Directive, federal departments), EU AI Act Article 27 FRIA (statutory; public bodies, private operators providing public services, §5(b)/§5(c) deployers), and generic enterprise AI risk assessment (internal; ISO 23894 / NIST AI RMF aligned). Not substitutes: different statutory anchors, different scopes, different content requirements.
• Canada AIA structure. 51 risk questions + 50 mitigation questions producing a numeric score that maps to Impact Levels I-IV. Tier-specific mitigation requirements under Appendix C (peer review, training, contingency, notice to clients, explanation, source-code release where possible, recourse mechanisms). Binding on federal departments under the Directive on Automated Decision-Making (2019, updated April 2023).
• Article 27 FRIA scope and content. Required for bodies governed by public law, private operators providing public services, and §5(b)/§5(c) deployers. Content under 27(1)(a)-(f). Notification to market surveillance authority under 27(3). DPIA coordination under 27(4). Commission template forthcoming under 27(5).
• Generic enterprise AI risk assessment. No statutory anchor; framework-aligned to ISO 23894 and NIST AI RMF 1.0. Six sections: system description, risk identification, risk analysis, risk evaluation, risk treatment, monitoring and review. The artifact the AI Governance Committee actually reads at monthly portfolio review; FRIA and AIA attached as exhibits.
• Decision-tree criteria. Deployer type, jurisdiction of deployment, Annex III category, downstream-affected-persons criteria, Article 25 transfer status. Walk the five questions in order; the artifact obligations fall out cleanly.
• Multi-jurisdiction reality. A multinational with 50 AI systems will typically run ~10 generic-only, ~20 generic + Article 50 transparency, ~12 Article 27 FRIA, ~3 Canada AIA, and ~5 combined DPIA/FRIA. Coordination through a single intake document and a combined DPIA/FRIA template is the operational pattern.
• Combined DPIA/FRIA template. Article 27(4) explicitly allows the FRIA to complement the DPIA. Seven-section template (system description, processing/period, affected persons, specific risks, oversight, mitigation, notification) cross-walks Article 35(7)(a)-(d) to Article 27(1)(a)-(f). Reduces effort 40-60% versus separate artifacts.
• §5(b)/§5(c) Aug 2, 2026 track. EU banks doing credit scoring and EU life/health insurers doing risk-based pricing face the universal-deployer FRIA obligation on the Aug 2, 2026 sectoral track, separate from the Dec 2, 2027 stand-alone Annex III deployment date.
• Cross-walks to ISO 42001, NIST AI RMF, SR 11-7. ISO 42001 A.5 (impact assessment) and A.6.1.1 (considerations) consume the same content; NIST AI RMF Map 5 consumes the same analysis; SR 11-7 model-risk management applies on top for AI-enabled banking models. Write the analysis once, cite it five times.
• Six common mistakes. Confusing the three artifacts; FRIA without DPIA; missing Canada AIA for federal deployments; missing the §5(b)/§5(c) Aug 2, 2026 track; weak deployer-type analysis; static decision tree. The decision-tree memo is a living document with quarterly review plus triggered updates.