Annex C
Annex C. Risk-Tier Classification Rubric
| Version | 1.0 |
| Current as of | June 4, 2026 |
| Document owner | AI Governance Committee |
| Publication status | Illustrative operating model for a hypothetical company. This annex is not legal advice, does not create an attorney-client relationship, and should be adapted to the Company's sector, market footprint, regulatory perimeter, contracts, and risk appetite before implementation. |
Section 1
Purpose
This rubric converts intake facts into a risk tier and a control path. It does not classify a system by model name, vendor, novelty, or internal enthusiasm. It classifies the actual use: what the system does, whose interests it affects, what a failure can change, whether a person can intervene in time, which data it uses, which legal regimes it touches, and what evidence exists to support the classification.
The reviewer uses this annex at Gate 0 to classify a proposed AI system, again at any material change, and again if monitoring shows that the original classification no longer describes the system in operation. The output of the rubric is not only a label. The output is a documented decision, a set of required controls, and a record that a future reviewer can reconstruct without interviewing the original team.
Section 2
Operating Rule
The Company applies five classification rules in order.
If a prohibited-use trigger applies, the use stops at intake unless the AI Governance Committee confirms that the trigger does not apply.
If an automatic high-risk trigger applies, the use is high-risk even if the scoring worksheet would otherwise produce a lower result.
If no automatic trigger applies, the reviewer scores the system across the risk dimensions in Section 5 and applies the escalation rules in Section 6.
If a use case sits between two tiers, the reviewer assigns the higher tier until the use-case owner produces evidence that supports the lower tier.
If a single system supports materially different uses, the reviewer classifies each use separately. The system-level registry record carries the highest tier, while the use-case record preserves the tier and controls for each use.
Section 3
Inputs Required Before Classification
The reviewer must have enough evidence to answer the classification questions without relying on the use-case owner's intent alone. A classification made without the following inputs is provisional and cannot clear Gate 0.
| Input | Minimum evidence required | Control reason |
|---|---|---|
| Use-case statement | Plain-language description of the decision, recommendation, action, content, or workflow the system will support. | Prevents classification by model name or vendor label. |
| Affected population | Who sees the output, who is acted on, who can be denied, routed, scored, ranked, monitored, or exposed. | Identifies rights, access, safety, employment, customer, client, and vulnerable-population risk. |
| Output type | Prediction, recommendation, score, ranking, classification, generated content, code, retrieval answer, autonomous action, or workflow trigger. | Determines whether the system informs, influences, or executes. |
| Human oversight design | Who reviews the output, what they can override, when they see it, and whether the process records the review. | Separates advisory tools from systems that materially shape outcomes. |
| Data categories | Public data, internal data, personal data, sensitive personal data, biometric data, protected health information, nonpublic information, client confidential material, credentials, security logs, or regulated records. | Determines privacy, security, confidentiality, privilege, and sector-control requirements. |
| Build, fine-tune, procure, or deploy status | Whether the Company builds the system, adapts a third-party model, procures a system, embeds a vendor feature, or deploys a customer-facing configuration. | Determines provider, deployer, vendor-diligence, and documentation obligations. |
| Jurisdiction and market | Where the system is developed, made available, used, monitored, or applied to affected persons. | Determines whether EU, federal, state, sector, and local overlays attach. |
| Scale and rollout path | Pilot, internal limited release, production release, customer release, enterprise release, public release, or customer-resold capability. | Determines aggregate harm, monitoring burden, and staged-release controls. |
| Vendor and model evidence | Model card, intended-use documentation, known limitations, evaluation results, data-provenance documentation, security review, contractual controls, audit rights, and change-notice terms. | Determines whether the Company has enough evidence to deploy, modify, or rely on the system. |
| Failure and remedy analysis | What can go wrong, who would notice, how fast the Company can reverse the outcome, and what remedy exists for affected persons. | Determines whether an error is recoverable, material, or unacceptable. |
Section 4
Prohibited-Use Screen
The prohibited-use screen asks whether the proposed use falls outside law or outside the Company's risk appetite. The reviewer records "yes," "no," or "unclear" for each trigger. A "yes" stops the use. An "unclear" routes to Legal and the AI Governance Committee before any development, procurement, pilot, or release proceeds.
| Trigger | Observable behavior | Governance implication | Required control |
|---|---|---|---|
| Manipulative or deceptive harm | The system uses hidden, deceptive, or materially manipulative techniques to impair a person's ability to make an informed decision in a way likely to cause significant harm. | The Company cannot treat consent, disclosure, or ordinary review as enough. | Stop at intake. Legal and Committee review only to confirm classification and document refusal. |
| Exploitation of vulnerability | The system exploits age, disability, economic position, social position, dependency, or similar vulnerability to distort behavior in a way likely to cause significant harm. | The use converts personalization into exploitation. | Stop at intake. Record affected group, proposed mechanism, and refusal rationale. |
| Social scoring | The system evaluates or classifies people over time based on social behavior or inferred personal traits and produces unrelated, unjustified, or disproportionate adverse treatment. | The risk is structural, not merely model-performance related. | Stop at intake. Committee confirms refusal and preserves the record. |
| Criminal-risk prediction based solely on profiling | The system predicts criminal-offense risk based solely on profiling, personality traits, or personal characteristics, rather than objective and verifiable facts tied to a specific criminal activity. | The use is not appropriate for Company deployment outside a legally authorized public-sector framework. | Stop at intake. Legal must confirm whether any lawful exception exists. |
| Untargeted facial database scraping | The system creates or expands a facial-recognition database through untargeted scraping of internet or CCTV images. | The data-acquisition method itself creates the prohibited risk. | Stop at intake. Security and Legal preserve vendor and data-source records. |
| Workplace or education emotion inference | The system infers emotions in workplace or education settings, except where Legal confirms a medical or safety basis. | The risk cannot be cured by accuracy testing alone. | Stop or route to Legal and Committee for written exception review. |
| Sensitive biometric categorization | The system categorizes people from biometric data to infer race, political opinion, trade-union membership, religious or philosophical belief, sex life, sexual orientation, or similar protected characteristics. | The output creates a protected-attribute inference that the Company should not operationalize. | Stop at intake unless Legal confirms a narrow lawful basis and Committee approves. |
| Unauthorized public biometric identification | The system performs real-time remote biometric identification in publicly accessible spaces without a lawful authorization pathway that applies to the Company and the use. | The use carries public-rights and surveillance risk beyond ordinary enterprise governance. | Stop at intake. No pilot may proceed on business-owner approval alone. |
| Final adverse decision without review | The system makes a final denial, termination, suspension, account closure, benefit denial, employment decision, credit decision, or legal-position decision with no meaningful human review, override path, notice path, or appeal path. | The Company cannot show controlled reliance or remediation. | Stop as designed. The use may be resubmitted only with human oversight, notices, logs, and appeal controls. |
| Unlawful or undocumented data basis | The system requires data the Company cannot lawfully use, cannot trace, cannot protect, or cannot contractually receive. | The issue is not the tier. The issue is lack of lawful and evidentiary foundation. | Stop until Legal, Privacy, Security, and Procurement clear the data basis and vendor commitments. |
Section 5
Automatic High-Risk Triggers
The Company treats the following uses as high-risk without waiting for score aggregation. The reviewer may not downgrade one of these uses unless Legal and the AI Governance Committee document why the trigger does not apply to the actual use.
| Trigger family | Use is high-risk when the system does any of the following | Controls that attach |
|---|---|---|
| Legal rights, access, or eligibility | Decides, ranks, scores, recommends, or materially shapes access to credit, lending, insurance, housing, education, employment, public benefits, essential private services, or other material opportunities. | Full gate sequence, bias and performance evaluation, human oversight, decision logging, notice and appeal analysis, monitoring, and Committee sign-off. |
| Employment and worker management | Screens candidates, ranks applications, evaluates employees, recommends promotion or termination, allocates work based on personal traits or behavior, monitors performance, or substantially assists a hiring or promotion decision. | High-risk classification plus employment-law, notice, bias-audit, and local-law review where applicable. |
| Finance and customer standing | Approves, denies, prices, freezes, blocks, suspends, closes, or materially affects a customer's account, access to funds, fraud status, AML status, credit position, insurance position, or adverse-action outcome. | Full gate sequence, fair-lending or consumer-protection review, model validation, adverse-action analysis, security review, and incident path mapping. |
| Biometric and identity systems | Identifies, verifies, categorizes, monitors, or authenticates people through biometric or behavioral characteristics, especially where an error affects access, surveillance, fraud status, employment, or customer treatment. | Legal, Privacy, Security, and Committee sign-off; liveness, accuracy, bias, spoofing, retention, and consent controls. |
| Health, safety, or patient-impact systems | Triage, diagnosis, treatment support, clinical prioritization, medical-device functionality, safety-critical operation, emergency dispatch, or any patient-impact system using protected health information or clinical data. | Route to Healthcare review, FDA and HIPAA analysis where applicable, clinical validation, safety monitoring, and Committee sign-off. Healthcare should not remain inside a generic Other path. |
| Legal-services or law-firm reliance | Analyzes privileged or confidential client material, drafts or changes work product a lawyer files or relies on, supports conflicts, matter intake, e-discovery, investigations, litigation strategy, legal advice, or professional-responsibility decisions. | Client-confidentiality, privilege, competence, supervision, matter-specific authorization, validation, and partner or legal-owner sign-off. |
| Critical infrastructure or security control | Operates as a safety component in critical digital infrastructure, controls access to production systems, initiates security actions, triages incidents at scale, changes permissions, or executes remediation with material operational effect. | Security architecture review, adversarial testing, rollback, kill switch, logging, incident integration, and senior technical sign-off. |
| Public or customer-facing generative content at scale | Generates, materially alters, ranks, or publishes content to customers or the public in a way that can mislead, defame, impersonate, manipulate, produce regulated advice, or affect market or civic behavior. | Disclosure, provenance, content-safety controls, monitoring, escalation thresholds, and release conditions. |
| Frontier or high-impact capability | Develops, fine-tunes, releases, or materially changes a model or agentic system with capabilities that can materially enable cyber abuse, biological or chemical misuse, large-scale fraud, autonomous harmful action, or other catastrophic or systemic harm. | Frontier-model safety review, capability evaluation, misuse testing, red-team evidence, deployment gating, incident reporting path, board or senior-governing-body visibility, and documented residual-risk acceptance. |
| EU high-risk category | Falls within EU AI Act Article 6 or Annex III high-risk categories, including qualifying biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, asylum, border control, justice, or democratic-process uses, when the system touches the EU market or affected persons in the EU. | EU role determination, provider or deployer obligation mapping, technical-documentation plan, conformity or registration analysis, human oversight, post-market monitoring, and serious-incident path. |
| Provider-status change | The Company puts its name or trademark on a high-risk system, substantially modifies a high-risk system, or changes the intended purpose of a system so that it becomes high-risk. | Article 25 provider-status analysis for EU-market activity, provider-grade documentation, vendor cooperation terms, and Committee sign-off before release. |
Section 6
Scoring Worksheet for All Other Uses
If no prohibited-use or automatic high-risk trigger applies, the reviewer scores each dimension from 0 to 3. The score records the evidence visible at classification. It does not replace judgment, and it does not override the automatic triggers above.
| Dimension | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Consequence severity | Output has no meaningful effect beyond convenience or drafting support. | Error causes minor, recoverable inconvenience. | Error causes material inconvenience, customer friction, operational delay, or reputational exposure. | Error affects rights, safety, finances, employment, legal position, health, essential access, regulatory standing, or material operations. |
| Decision influence | Output does not affect a decision. | Output informs a human who independently decides and records review. | Output substantially assists, ranks, scores, prioritizes, or becomes the default recommendation. | Output makes or initiates the decision, or a human review is nominal, late, undocumented, or practically ineffective. |
| Autonomy and action | System only drafts, retrieves, or summarizes. | System recommends an action but cannot execute it. | System executes bounded internal actions with approval, logs, and rollback. | System executes external, customer, legal, financial, security, or operational actions without timely human approval. |
| Data sensitivity | Public, synthetic, or approved non-sensitive data. | Internal business data with no personal, confidential, privileged, or regulated content. | Personal data, confidential business data, customer records, vendor records, or production telemetry. | Sensitive personal data, biometric data, protected health information, nonpublic information, credentials, security logs, trade secrets, privileged material, or client confidential material. |
| Scale and affected population | Individual or narrow internal pilot. | Limited internal team or controlled sandbox. | Business-unit, customer cohort, vendor, or recurring production workflow. | Enterprise, public, cross-market, high-volume, vulnerable-population, protected-group, or customer-resold deployment. |
| Reversibility and remedy | Error can be corrected immediately with no practical harm. | Error can be corrected quickly and affected persons can be identified. | Error can be corrected only with operational effort, customer contact, remediation, or reprocessing. | Error is hard to detect, hard to reverse, deadline-sensitive, legally consequential, safety-relevant, or practically irreversible. |
| Explainability and evidence | Reviewers can explain the output basis and reproduce the relevant records. | The system provides reasonable explanation and logs, but some model behavior remains opaque. | Explanation is limited, vendor evidence is incomplete, or reviewers cannot reliably reconstruct the output basis. | The Company cannot explain, test, reproduce, audit, or obtain evidence sufficient for the intended use. |
| Legal and regulatory adjacency | No apparent legal, regulatory, contractual, or supervisory implication. | Transparency, disclosure, copyright, data-use, or contractual review may attach. | Sector-specific, employment, privacy, cybersecurity, procurement, consumer, or professional-duty review likely attaches. | Statutory high-risk classification, supervisory examination, reporting duty, regulated adverse action, legal reliance, or serious-incident duty may attach. |
| Model-change behavior | Static workflow, rules engine, or approved model with no material adaptation. | Model changes only through controlled release management. | System uses a foundation model, fine-tuning, retrieval augmentation, or frequent vendor-side changes requiring monitoring. | System adapts, acts agentically, self-improves, chains tools, changes behavior through open-ended prompts, or relies on a model with high-impact capability. |
| Misuse, abuse, and security potential | No realistic misuse beyond ordinary user error. | Misuse could expose internal information or create low-level process errors. | Misuse could expose confidential data, enable impersonation, bypass controls, or trigger incorrect operational action. | Misuse could enable cyber abuse, fraud, identity compromise, market manipulation, physical harm, regulated-data compromise, or large-scale external harm. |
Section 7
Score Interpretation and Escalation Rules
The reviewer applies the following result after scoring.
| Result | Standard | Classification outcome |
|---|---|---|
| Minimal-risk | No prohibited or automatic high-risk trigger applies, no dimension scores 3, no more than one dimension scores 2, and total score is 0 to 5. | Registry entry, use-case-owner attestation, acceptable-use constraints, and periodic sample audit. |
| Limited-risk | No prohibited or automatic high-risk trigger applies, no escalation rule below applies, and total score is 6 to 14. | Registry entry, lightweight gate review, disclosure where relevant, proportionate vendor diligence, spot-check evaluation, monitoring, and reassessment trigger. |
| High-risk by score | Total score is 15 or higher. | High-risk controls apply. |
| High-risk by concentration | Two or more dimensions score 3, even if the total is below 15. | High-risk controls apply. |
| High-risk by consequence and influence | Consequence severity scores 3 and decision influence scores 2 or 3. | High-risk controls apply. |
| High-risk by autonomy | Autonomy and action scores 3 and consequence severity scores 2 or 3. | High-risk controls apply. |
| High-risk by data and external effect | Data sensitivity scores 3 and the output affects a customer, client, employee, applicant, patient, regulated user, or external person. | High-risk controls apply unless Legal, Privacy, Security, and the Committee document why limited-risk controls are sufficient. |
| Provisional pending evidence | The reviewer lacks evidence for data rights, vendor testing, system limitations, human oversight, security posture, or intended use. | The system cannot clear Gate 0 except for a controlled evaluation that uses approved data, has no external effect, and has a named owner. |
Section 8
Tier Outcomes and Required Controls
| Tier | Decision consequence | Required controls |
|---|---|---|
| Prohibited | The Company does not pursue the use as proposed. | Intake stop, Committee record, Legal confirmation where needed, refusal rationale, and no procurement, pilot, development, or release until redesign removes the trigger. |
| High-risk | The system may proceed only through the full governance path. | Full review gates, named accountable owner, Legal review, Privacy review where applicable, Security review, validation-owner review, bias and performance evaluation, data-rights review, human oversight, decision logs, vendor diligence, enhanced registry fields, monitoring thresholds, incident path, and Committee sign-off before deployment. |
| Limited-risk | The system may proceed through a proportionate governance path. | Gate 0 classification, registry entry, documented owner, disclosure where people interact with AI or synthetic content, proportionate vendor review, spot-check testing, security baseline, monitoring trigger, and escalation if scope changes. |
| Minimal-risk | The system may proceed on attestation and registry capture. | Registry entry, use-case-owner attestation, approved-tool or approved-environment use, no regulated data without separate approval, no customer or external effect without reclassification, and periodic sample audit. |
Section 9
Control Map by Observable Risk Factor
This map prevents the classification from ending as a label. Each observable risk factor creates a governance implication and a control record.
| Observable risk factor | Governance implication | Required control record |
|---|---|---|
| The system can deny, rank, score, or materially shape access to a right, service, job, account, benefit, or legal position. | The Company must show controlled reliance, fairness review, and an affected-person remedy. | Decision log, human-review design, adverse-action or notice analysis, bias and performance test, override path, and remediation plan. |
| The system handles sensitive, regulated, privileged, confidential, or security-relevant data. | The Company must prove lawful use, least-privilege access, retention control, and vendor restrictions. | Data inventory, lawful-basis or data-rights memo, security review, retention rule, access controls, vendor data-use terms, and prompt or output retention decision. |
| The system acts without a person approving the specific action. | The Company must show bounded autonomy and recoverability. | Action boundary, approval rule, rollback mechanism, kill switch, audit log, monitoring threshold, and escalation owner. |
| The system's output reaches customers, clients, applicants, employees, patients, users, regulators, or the public. | The Company must control disclosure, reliance, consumer or professional duty, and harm remediation. | Disclosure assessment, user-facing language owner, content-safety checks, complaint path, monitoring plan, and incident routing. |
| The system relies on a vendor model or embedded vendor feature. | The Company must connect the running system to diligence and contract evidence. | Vendor checklist, model or system documentation, known limitations, evaluation results, audit rights, change-notice terms, indemnity position, and subcontractor or model-supplier flow-down. |
| The system uses a foundation model, fine-tuning, retrieval augmentation, tool use, or agentic orchestration. | The Company must manage model lineage, inherited risk, prompt or retrieval behavior, tool permissions, and drift. | Model lineage record, version record, retrieval-source approval, tool permission matrix, evaluation set, red-team result where appropriate, and change-control rule. |
| The system touches the EU market or affected persons in the EU. | The Company must determine whether it acts as provider, deployer, importer, distributor, or more than one role. | EU role memo, Article 6 and Annex III classification record, Article 25 provider-status analysis where relevant, Article 50 transparency analysis where relevant, and crosswalk update. |
| The system supports California-facing public generative AI or materially modified generative AI. | Training-data documentation may become a documentation overlay. It does not by itself make every use high-risk. | Developer or vendor training-data documentation review, public-availability analysis, substantial-modification record, and publication or vendor-evidence link. |
| The system operates in a NYDFS-regulated financial institution. | AI cybersecurity risk must sit inside the existing Part 500 cybersecurity framework rather than a disconnected AI review. | Part 500 control mapping, third-party service-provider assessment, nonpublic-information review, incident routing, and senior-governing-body reporting where applicable. |
| The system supports NYC hiring or promotion through an automated employment decision tool. | Bias-audit and notice obligations may attach in addition to the high-risk classification. | AEDT analysis, bias-audit record, public-posting owner, candidate or employee notice path, and annual review date. |
| The system has patient-impact, medical-device, clinical, or protected-health-information exposure. | Healthcare review is not a generic Other-sector review. | Healthcare-sector escalation, HIPAA or data-use review, FDA or SaMD assessment where applicable, clinical validation plan, and patient-safety monitoring. |
Section 10
Boundary Guidance for Common Classification Calls
| Use pattern | Usual tier | Why | Required condition for the tier to hold |
|---|---|---|---|
| Internal drafting assistance for non-regulated, non-confidential content. | Minimal-risk | The output does not affect a person, right, service, account, customer, client, or regulated decision. | User remains responsible, no sensitive data enters the tool, and no external publication occurs without ordinary review. |
| Internal summarization of confidential but non-regulated business material. | Limited-risk | Confidentiality and data-retention risk attach even if no external decision results. | Approved tool, access control, retention rule, and no external effect. |
| Customer-service chatbot with clear disclosure and no authority to decide, deny, refund, price, suspend, or escalate adversely. | Limited-risk | The system interacts with people but the consequence of error remains bounded and recoverable. | Disclosure, retrieval-source control, human escalation, monitoring, and no regulated advice. |
| Customer-service chatbot that can deny a claim, close a case, refuse service, trigger collections, or affect account standing. | High-risk | The output materially affects access, finances, or customer standing. | Full high-risk controls. |
| Internal legal research or drafting assistant used by a lawyer who reviews every output before reliance. | Limited-risk | Professional-duty risk exists, but supervised use can keep the system below high-risk where no client decision or filing relies on unchecked output. | Matter-owner supervision, citation validation, confidentiality controls, and no direct filing or client advice without lawyer review. |
| Legal or compliance system that drafts, approves, or materially shapes advice, filings, investigations, privilege calls, conflicts, or client work product without meaningful expert review. | High-risk | The system can change a legal outcome, professional duty, privilege posture, or client position. | Full high-risk controls. |
| Recommendation or ranking engine that affects content order but not access, eligibility, protected groups, material opportunity, safety, employment, or financial outcome. | Limited-risk | Ranking affects user experience, but harm remains bounded absent scale, protected-group, market, safety, or civic effects. | Monitoring, transparency assessment, abuse testing where relevant, and escalation if the surface becomes consequential. |
| Recommendation, ranking, or moderation system that materially affects visibility, safety, speech exposure, marketplace access, protected groups, minors, civic information, or livelihood. | High-risk | Scale and affected-population risk convert ranking into a consequential control. | Full high-risk controls. |
| Fraud, AML, or trust-and-safety model that flags activity for human review only. | Limited-risk or high-risk depending on consequence. | A flag may stay limited if it merely queues review, but it becomes high-risk when it blocks, freezes, terminates, or materially changes standing. | Document whether the system queues review or triggers action. |
| Fraud, AML, or trust-and-safety model that freezes funds, blocks access, terminates accounts, or reports a person. | High-risk | The system changes financial access, legal exposure, or customer standing. | Full high-risk controls. |
| Code-completion tool used by engineers inside approved repositories. | Minimal-risk or limited-risk depending on environment. | Ordinary code assistance may stay minimal, but production, security, license, or data exposure can raise the tier. | Security review, license controls, secret-detection controls, and ordinary code review. |
| Agentic workflow that executes purchases, payments, account changes, production changes, notices, filings, or security actions. | High-risk | The system acts in the world, and autonomy compounds ordinary workflow risk. | Action boundaries, approval gates, logs, rollback, kill switch, and Committee sign-off where external or regulated effect exists. |
| Fine-tuned third-party foundation model for a high-risk use. | High-risk | The Company may move from ordinary deployer posture into provider-grade obligations in the EU and provider-like evidence expectations elsewhere. | Model lineage, data provenance, Article 25 analysis where EU activity exists, provider-grade testing, and vendor cooperation terms. |
| Public generative AI feature that creates image, audio, video, or text content for users. | Limited-risk or high-risk depending on effect and scale. | Disclosure and provenance obligations may attach even where the use is not high-risk. The tier rises when the feature can mislead, impersonate, manipulate, affect regulated decisions, or create systemic misuse. | Disclosure, provenance, content-safety, abuse monitoring, and legal review for market-specific duties. |
Section 11
Reclassification Triggers
The AI Governance Office reopens classification when any trigger below occurs. The use-case owner must notify the AI Governance Office before the change goes live.
| Trigger | Why it matters |
|---|---|
| Intended purpose changes. | A low-risk tool can become high-risk when pointed at a consequential decision. |
| Human review changes. | Removing, delaying, or weakening review changes decision influence and accountability. |
| Autonomy increases. | Adding tool use, external actions, workflow execution, or agentic chaining can move the system to high-risk. |
| Data categories change. | Adding personal, sensitive, biometric, protected health, nonpublic, privileged, client, or security data changes the control baseline. |
| Market or jurisdiction changes. | EU, California, New York, sector, and customer-contract overlays can attach because the system enters a new market or affects new people. |
| Model, vendor, or version changes. | A new base model, fine-tune, retrieval corpus, vendor release, training-data posture, or contractual term can change risk and evidence. |
| Scale increases. | A pilot can become high-risk when repeated at customer, enterprise, public, or cross-market scale. |
| Output reaches a new audience. | Internal outputs become more consequential when customers, clients, applicants, employees, patients, regulators, or the public see or rely on them. |
| Monitoring shows drift or unexpected harm. | The operating system, not the launch memo, controls the real risk. |
| A complaint, incident, audit issue, regulatory inquiry, or vendor notice occurs. | External signals can show that the original classification no longer holds. |
Section 12
Classification Decision Record
The reviewer completes the decision record below and attaches it to the registry entry. The record must be complete enough that an internal auditor, regulator, customer, or successor owner can understand the basis for the tier without recreating the review.
| Field | Required entry |
|---|---|
| System name | Name, version, vendor or internal owner, and registry ID. |
| Use case | Specific use being classified. If the system has multiple uses, identify the use to which this record applies. |
| Sector, posture, and jurisdiction | Finance, Tech, Law Firm, or Other; builds, deploys, or both; NY, CA, International, and EU-market activity if different from International. |
| Classification owner | Person accountable for completing the rubric. |
| Date and review cadence | Classification date, next review date, and event-based reassessment triggers. |
| Proposed tier | Tier requested by the use-case owner. |
| Final tier | Tier assigned by the AI Governance Office or Committee. |
| Prohibited-use screen | Yes, no, or unclear for each prohibited-use trigger, with rationale for any unclear or no answer that required judgment. |
| Automatic high-risk triggers | Trigger applied or "none," with evidence. |
| Scoring worksheet | Score for each dimension, total score, and evidence for each score of 2 or 3. |
| Controls assigned | Gate path, owners, testing, diligence, disclosures, human oversight, monitoring, incident routing, and required artifacts. |
| Conditions before release | Any condition that must be satisfied before development, procurement, pilot, production, customer release, or public release. |
| Exceptions or downgrades | Any request to classify below an automatic or score-indicated tier, with Legal and Committee approval. |
| Approval record | Names, roles, decision date, dissent if any, and residual-risk owner. |
Section 13
Source Basis and Volatility Note
This annex aligns to NIST AI RMF Govern, Map, Measure, and Manage functions; ISO/IEC 42001's management-system approach to AI risk; and the EU AI Act's risk-tier structure. It treats EU AI Act Article 5 prohibited practices, Article 6 high-risk classification, Annex III high-risk areas, Article 25 value-chain provider-status rules, and Article 50 transparency obligations as binding overlays when EU-market activity exists. It also treats the European Commission's May 19, 2026 draft high-risk classification guidelines as current interpretive guidance, not final law.
The U.S. state-law layer remains volatile. California's AB 2013 creates a developer training-data documentation requirement for public generative AI systems and substantial modifications made available to Californians; it does not by itself make every California-facing generative AI use high-risk. California's SB 53 creates additional obligations for frontier developers and large frontier developers as defined in that statute, so this annex treats frontier or high-impact capability as a high-risk governance trigger but not as a universal statutory trigger. NYC Local Law 144 creates bias-audit, public-posting, and notice obligations for covered automated employment decision tools. NYDFS's October 16, 2024 AI cybersecurity guidance explains how covered entities should use existing Part 500 cybersecurity obligations to address AI risk and states that it does not impose new requirements. Healthcare uses require separate analysis because HIPAA, FDA medical-device regulation, SaMD guidance, clinical validation, and patient-impact controls can attach in ways this generic sector path should not absorb.
Julio Macedo
Senior Attorney | AI Governance & Legal Ops
jhmacal.com