Annex A

Annex A. AI Use Case Intake Form and Routing Logic

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, procurement process, contracts, and risk appetite before implementation.

Section 1

Purpose

This annex is the front door to the AI governance program. It gives the Company a single intake form, a routing standard, and a required attachment schedule so that AI systems enter the governance machinery before the decision to build, buy, fine-tune, embed, deploy, or repurpose has already become too expensive to stop.

The form deliberately asks for observable facts rather than conclusions. The use-case owner does not decide whether the system is low-risk, limited-risk, high-risk, or prohibited. The use-case owner describes what the system does, who it affects, what data it uses, whether it acts or advises, where it will run, and what evidence exists. The AI Governance Office uses those facts to assign a provisional tier, route the review, populate the registry, and trigger the right gates.

Section 2

Intake Trigger Standard

Intake is mandatory at the earliest trigger below. A system may not proceed to development, procurement approval, vendor execution, pilot, production release, customer release, public release, or material repurposing until the intake record exists.

Trigger	Observable event	Required submission point	Governance reason
Build intent	A team decides to design, code, train, fine-tune, adapt, or assemble an AI system, including use of open weights or a third-party foundation model.	Before design work begins beyond exploration with approved test data.	Brings internally developed systems into scope before architecture, data, and model choices harden.
Procurement touchpoint	A purchase, renewal, RFP, security review, privacy review, contract amendment, statement of work, or vendor feature request touches AI.	Before procurement approval, vendor selection, or contract signature.	Catches AI embedded inside vendor products and prevents governance from arriving after the contract fixes the risk.
Vendor feature activation	A licensed product adds, enables, or materially changes an AI feature.	Before feature activation in any production or customer-facing environment.	Prevents shadow AI introduced through software the business already owns.
Fine-tuning or model adaptation	A team modifies, fine-tunes, retrains, distills, wraps, or changes the intended purpose of a model supplied by another party.	Before model adaptation begins.	Creates the provider-status, lineage, data-rights, and documentation record before the Company crosses from deployment into modification.
Agentic capability	The system can call tools, execute workflow steps, trigger transactions, change records, send communications, alter permissions, or act outside a chat response.	Before any connection to production systems or external tools.	Routes autonomy, rollback, permissions, and kill-switch controls before the system can act.
External exposure	The output reaches customers, clients, applicants, employees, patients, regulators, users, counterparties, vendors, or the public.	Before pilot or release.	Triggers disclosure, reliance, notice, remedy, professional-duty, consumer, and monitoring review.
Regulated or sensitive data	The system uses personal data, sensitive personal data, biometric data, protected health information, nonpublic information, privileged material, client confidential material, credentials, security logs, trade secrets, or regulated records.	Before data connection, upload, indexing, retrieval, training, or vendor transfer.	Prevents unlawful, insecure, or contractually unsupported data use.
Material change	The system changes purpose, population, data, model, vendor, market, scale, human oversight, autonomy, output audience, or production environment.	Before the change goes live.	Reopens classification when the operating reality no longer matches the original record.
Incident or complaint	A complaint, audit issue, vendor notice, drift signal, security event, suspected discrimination, hallucination pattern, adverse outcome, or regulatory inquiry arises.	Immediately upon discovery.	Routes the issue to monitoring, escalation, incident response, and potential reclassification.

Section 3

Intake Service Levels

The service level is part of the control. A slow intake process teaches teams to avoid it. The AI Governance Office owns the response clock once the use-case owner submits a complete record.

Intake result	Response commitment	What the response must include
Completeness check	1 business day	Complete, incomplete, or rejected as out of scope. If incomplete, the missing fields must be listed.
Minimal-risk provisional clearance	1 business day after complete submission	Registry ID, owner attestation, approved-use limits, and reassessment triggers.
Limited-risk routing	3 business days after complete submission	Provisional tier, required reviewers, required attachments, disclosure check, vendor-diligence requirement, and target gate date.
High-risk or contested routing	5 business days after complete submission	Scoping response, required diligence stack, committee path, gate sequence, review owner, and expected decision timeline.
Prohibited-use concern	1 business day after issue identified	Intake hold, Legal owner, Committee confirmation path, and preservation of the refusal record.
Urgent business exception request	2 business days after complete exception request	Approve, deny, or conditionally approve limited evaluation only. No exception may authorize external effect, regulated data use, or high-risk deployment without Committee approval.

Section 4

Required Intake Form

The intake form below is the required first submission. The AI Governance Office may request the conditional addenda in Section 5, but it may not require a team to complete every addendum before provisional routing unless the intake answers make that addendum relevant.

A. Intake Metadata

Field	Required response	Routing use
Intake ID	Assigned by intake workflow.	Links the form to the registry, gates, contracts, and incidents.
Submission date	Date submitted.	Starts the service-level clock.
Use-case name	Plain-language name.	Creates the registry record and review queue item.
Use-case owner	Named business, product, legal, engineering, or practice owner.	Assigns operating accountability.
Accountable executive	Named executive or partner accountable for the use if approved.	Identifies residual-risk owner for Gate 3.
Submitting team	Team, business unit, product group, practice group, or corporate department.	Routes sector and control alignment.
Requested launch date	Pilot, internal release, production release, customer release, or public release date.	Determines review urgency and whether the request is late.
Current status	Idea, experiment, vendor evaluation, contract negotiation, development, pilot, production, renewal, feature activation, material change, or incident-driven review.	Determines which lifecycle gate is active.

B. Configuration and Market Facts

Field	Required response	Routing use
Sector path	Finance, Tech, Law Firm, Other, or Healthcare review needed.	Selects representative uses, gate alignment, and sector overlays.
Posture	Builds, deploys, or both.	Determines build, provider, deployer, vendor, and lineage evidence.
Jurisdiction path	NY, CA, International, or more than one.	Selects statutory overlay.
EU-market activity	Yes, no, or unclear. Identify whether the system is placed on the EU market, used in the EU, affects persons in the EU, or supports EU customers.	Separates EU-market activity from the generic International path and triggers EU role analysis.
California-facing activity	Yes, no, or unclear. Identify whether the system or service is made available to Californians.	Triggers California training-data, transparency, privacy, and public-facing generative AI review where applicable.
New York-facing activity	Yes, no, or unclear. Identify whether the system affects New York customers, employees, applicants, regulated operations, or DFS-covered activity.	Triggers NYDFS, NYC employment, and New York statutory overlay review where applicable.
Other regulated markets	Identify federal, state, sector, customer-contract, or non-U.S. markets known to the owner.	Captures obligations not covered by the selected front-end path.

C. System Description

Field	Required response	Routing use
What the system does	Describe the output in one paragraph: prediction, recommendation, score, ranking, classification, generated content, code, retrieval answer, workflow action, or other output.	Prevents classification by vendor or model label.
Business purpose	Describe the operational problem the system addresses.	Tests fit, necessity, and proportionality.
Users	Identify who operates the system.	Assigns training, access, and oversight controls.
Affected persons or groups	Identify who the output affects, including customers, clients, applicants, employees, patients, users, counterparties, vendors, protected groups, minors, vulnerable groups, or the public.	Determines fairness, notice, remedy, and high-risk classification.
Decision or workflow affected	Identify the decision, action, advice, publication, transaction, record, product behavior, or legal position the output may influence.	Determines consequence severity and review gate.
Human oversight	Identify who reviews the output, when review occurs, what the reviewer can override, and whether the review is logged.	Determines whether the system advises, materially shapes, or decides.
Autonomy	Identify whether the system can execute actions, call tools, send messages, change records, initiate transactions, alter permissions, or release content.	Triggers agentic and security controls.
Scale	Identify pilot size, expected user count, affected-person volume, business-unit scope, customer scope, and public exposure.	Determines aggregate risk and rollout controls.
Remedy	Identify how the Company can detect, reverse, correct, notify, or remediate an error.	Determines reversibility and escalation path.

D. Data and Evidence

Field	Required response	Routing use
Input data	Identify each data source used in prompts, retrieval, training, fine-tuning, evaluation, or operation.	Populates registry and data-provenance review.
Data categories	Public data, internal data, personal data, sensitive personal data, biometric data, protected health information, nonpublic information, client confidential material, privileged material, credentials, security logs, trade secrets, or regulated records.	Triggers Legal, Privacy, Security, healthcare, and confidentiality controls.
Data rights	Identify known ownership, license, consent, contract, regulatory, or customer restrictions.	Determines lawful basis and vendor restrictions.
Data location	Identify where the data is stored, processed, transmitted, retained, indexed, logged, or viewed.	Triggers security, privacy, cross-border, and vendor-hosting review.
Training-data evidence	For generative AI or fine-tuning, identify available training-data documentation, vendor documentation, or internal dataset record.	Triggers California, EU, vendor, and provider-grade documentation review.
Vendor evidence	Attach model cards, system cards, intended-use statements, limitations, evaluation reports, bias testing, security materials, audit reports, AI terms, change-notice terms, and data-use commitments if available.	Determines whether the Company can rely on a vendor system.
Internal evidence	Attach evaluation plan, test results, prompt design, retrieval-source list, model lineage, validation dataset description, red-team results, security review, or release plan if available.	Determines whether built or adapted systems can advance to Gate 1 or Gate 2.

E. Risk and Control Questions

Question	Required response	Routing use
Can the system deny, rank, score, suspend, approve, price, prioritize, close, freeze, report, or materially affect a person, account, job, application, service, benefit, legal position, health outcome, or financial position?	Yes, no, or unclear. Explain.	Yes or unclear routes to Annex C high-risk trigger review.
Can the system create, modify, or publish content to customers, clients, users, regulators, counterparties, or the public?	Yes, no, or unclear. Explain.	Triggers disclosure, provenance, content-safety, and public-facing review.
Can the system impersonate, simulate, classify, identify, verify, monitor, or infer characteristics of a person?	Yes, no, or unclear. Explain.	Triggers biometric, profiling, privacy, employment, and prohibited-use review.
Can the system support employment, promotion, worker management, performance evaluation, hiring, staffing, or compensation decisions?	Yes, no, or unclear. Explain.	Triggers high-risk employment review and NYC AEDT analysis where applicable.
Can the system affect credit, funds, fraud status, AML status, account access, adverse action, customer standing, or regulated financial reporting?	Yes, no, or unclear. Explain.	Triggers finance high-risk review, fair-lending or consumer review, and NYDFS review where applicable.
Can the system touch privileged, confidential, client, litigation, investigation, conflicts, legal-advice, or professional-responsibility material?	Yes, no, or unclear. Explain.	Triggers law-firm or legal-services high-risk review.
Can the system affect diagnosis, triage, treatment, patient communications, clinical prioritization, medical-device functionality, safety, or protected health information?	Yes, no, or unclear. Explain.	Routes to Healthcare review and patient-impact controls.
Can the system execute actions without a person approving each action?	Yes, no, or unclear. Explain.	Triggers agentic controls, security review, rollback, kill switch, and autonomy scoring.
Can the system materially change after deployment through model updates, fine-tuning, retrieval-source changes, prompt changes, vendor updates, or self-learning behavior?	Yes, no, or unclear. Explain.	Triggers change-control and monitoring requirements.
Does any prohibited-use trigger in Annex C appear possible?	Yes, no, or unclear. Identify trigger.	Yes or unclear creates intake hold and Legal plus Committee routing.

Section 5

Conditional Addenda

The AI Governance Office attaches the addenda below only when the intake answers make them relevant.

Addendum	Trigger	Required content
Procurement addendum	Vendor system, vendor feature, renewal, RFP, SOW, contract amendment, or third-party model.	Vendor name, product name, AI feature description, contract status, data processed, audit rights, change-notice terms, vendor AI terms, subprocessor or model-supplier dependencies, and vendor evidence packet.
Build or fine-tune addendum	Internal build, model adaptation, fine-tuning, open-weights use, RAG system, or model wrapper.	Model lineage, base model, training or fine-tuning data, evaluation plan, validation dataset, security architecture, release plan, provider-status question, and monitoring plan.
Agentic addendum	Tool use, workflow execution, transaction initiation, record change, permission change, message sending, external action, or autonomous chain.	Tool list, permission scope, action boundaries, approval gates, logs, rollback, kill switch, monitoring, abuse case, and escalation owner.
Employment addendum	Hiring, promotion, worker management, performance scoring, candidate ranking, scheduling, staffing, productivity, or compensation use.	Job or worker population, decision influenced, human review, vendor role, bias-audit status, notice path, alternative process path, and annual review date.
Finance addendum	Credit, fraud, AML, funds access, account access, pricing, adverse action, regulatory capital, risk reporting, or customer standing.	Decision affected, customer impact, model validation plan, adverse-action analysis, fair-lending or consumer review, NYDFS applicability, and incident route.
Legal-services addendum	Client material, privileged material, legal advice, filings, investigation, e-discovery, conflicts, intake, matter staffing, or professional-duty use.	Matter type, confidentiality controls, privilege posture, supervisory lawyer, citation or source validation, client consent or notice if needed, and use limits.
Healthcare addendum	Patient-impact, clinical, PHI, diagnosis, triage, treatment, SaMD, medical-device, safety, payer, provider, or care-management use.	HIPAA or data-use analysis, FDA or SaMD screen where applicable, clinical validation, patient-safety owner, monitoring thresholds, and escalation path.
EU-market addendum	EU-market activity is yes or unclear.	EU role analysis, Article 6 and Annex III classification, Article 25 provider-status analysis where relevant, Article 50 transparency analysis where relevant, technical-documentation plan, registration question, and serious-incident route.
Public generative AI addendum	Public, customer-facing, user-facing, or third-party-facing generative AI feature or service.	Content type, disclosure approach, provenance or watermarking approach, abuse testing, moderation, complaint path, training-data documentation, and market-specific transparency obligations.
Exception request addendum	The owner seeks an urgent pilot, abbreviated review, conditional approval, or release before normal clearance.	Business need, proposed scope, data limits, affected population, external-effect limit, rollback, monitoring, expiration date, and residual-risk owner.

Section 6

Provisional Routing Logic

The intake workflow assigns a provisional route. The route does not decide final classification. It decides who must review the case and what evidence must attach.

Intake answer	Provisional route	Required next step
Out of scope because no AI system or AI-enabled capability is involved.	Close intake as out of scope.	Record reason and return to ordinary process.
Minimal-risk indicators only, no regulated data, no external effect, no sensitive data, no autonomy, no vendor gap, and no prohibited or high-risk trigger.	Minimal-risk provisional clearance.	Create registry record, owner attestation, approved-use conditions, and reassessment triggers.
User-facing or employee-facing interaction, internal confidential data, vendor AI feature, generative output, limited workflow influence, or bounded recommendation with human review.	Limited-risk review.	AI Governance Office confirms tier, assigns disclosure or transparency check, vendor review if applicable, and spot-check evaluation.
Any automatic high-risk trigger in Annex C appears present or unclear.	High-risk review.	Attach full evidence stack, assign Gate 1 and Gate 2 reviewers, and route to Committee when required.
Any prohibited-use trigger in Annex C appears present or unclear.	Intake hold.	Legal and Committee review before any build, procurement, pilot, or release.
Insufficient evidence for data rights, vendor limitations, human oversight, security, or intended use.	Provisional pending evidence.	Intake cannot clear except for controlled evaluation with approved data and no external effect.
Material change to an approved system.	Reclassification review.	Compare old and new purpose, population, data, model, vendor, market, scale, autonomy, and output audience.
Incident, complaint, drift, audit issue, or regulatory inquiry.	Escalation path.	Link to Annex F and suspend, limit, monitor, or reclassify as required.

Section 7

Attachment Schedule by Tier

Artifact	Minimal-risk	Limited-risk	High-risk	Prohibited or contested
Completed intake form	Required	Required	Required	Required
Registry record	Required	Required	Required	Required if refusal or contest must be preserved
Owner attestation	Required	Required	Required	Not sufficient
Annex C classification record	Summary only	Required	Required with full scoring and trigger analysis	Required with refusal or Committee rationale
Data-rights review	Only if non-public data is used	Required if personal, confidential, contractual, or regulated data is used	Required	Required if data basis created the hold
Privacy review	Not required unless personal data is used	Required if personal data is used	Required if personal, sensitive, biometric, employee, patient, or customer data is used	Required if privacy trigger created the hold
Security review	Approved-tool baseline	Required for vendor, confidential data, integration, or production use	Required	Required if security trigger created the hold
Vendor diligence	Approved vendor record if applicable	Proportionate checklist	Full checklist and contract review	Required if vendor evidence created the hold
Bias and performance evaluation	Not required beyond sample audit	Spot-check or targeted test	Required before deployment	Required if fairness concern created the hold
Human-oversight design	Owner attestation	Required where output shapes a decision	Required	Required for redesign
Disclosure or notice analysis	Not required unless user interaction exists	Required where people interact with AI or synthetic content	Required where affected persons, customers, employees, patients, clients, or public users are affected	Required if lack of notice created the hold
Monitoring plan	Periodic sample audit	Required	Required with thresholds and owner	Required if system runs under limited exception
Incident route	Standard route	Required	Required with severity triggers	Required if refusal, exception, or hold exists
Committee review	Not required	Only if contested or escalated	Required for high-risk deployment or residual-risk acceptance	Required

Section 8

Owner Attestation

The use-case owner must attest to the following before a system may receive minimal-risk clearance or proceed into limited-risk or high-risk review.

Attestation	Required owner statement
Accuracy	The description of the use case, affected population, data, vendor, model, market, and deployment status is complete and accurate to the best of the owner's knowledge.
No undisclosed external effect	The system will not affect customers, clients, applicants, employees, patients, users, regulators, counterparties, vendors, or the public except as described in the intake form.
No undisclosed sensitive data	The system will not use personal, sensitive, biometric, protected health, nonpublic, privileged, client confidential, credential, security-log, trade-secret, or regulated data except as described in the intake form.
No undisclosed autonomy	The system will not execute actions, call tools, change records, send communications, alter permissions, initiate transactions, or publish content except as described in the intake form.
No material change without reclassification	The owner will resubmit intake before changing purpose, population, data, model, vendor, market, scale, human oversight, autonomy, or output audience.
Evidence preservation	The owner will preserve vendor materials, test results, approval records, monitoring records, incident records, and release records linked to the system.

Section 9

Procurement Workflow Control

Procurement must include an AI flag before vendor selection and before contract signature. The flag should not ask whether the vendor sells an "AI product" only. It should ask whether the product, service, feature, integration, support tool, analytics layer, workflow engine, security tool, recruiting tool, customer-facing tool, or embedded capability uses AI or model-based outputs in any material way.

Procurement question	If yes or unclear
Does the vendor product, service, or feature generate content, predictions, recommendations, rankings, classifications, scores, decisions, code, summaries, or workflow actions?	Intake required before vendor selection or renewal approval.
Does the vendor process Company data, customer data, employee data, client data, patient data, security data, or regulated records through an AI system?	Intake, Privacy, Security, and vendor diligence required.
Does the vendor use Company data for training, fine-tuning, evaluation, improvement, logging, or human review?	Data-use terms, opt-out or prohibition terms, retention controls, and Legal review required.
Can the vendor materially change the model, feature, training data, intended use, subprocessors, model suppliers, or output behavior after signature?	Change-notice terms, reassessment trigger, and contract control required.
Does the product affect customers, applicants, employees, patients, clients, regulated users, financial access, legal work, safety, security, or public content?	Annex C classification and likely limited-risk or high-risk review required.

Section 10

Intake Outcomes

The AI Governance Office records one outcome before the case leaves intake.

Outcome	Meaning	Required record
Out of scope	The proposed item does not meet the playbook scope.	Reason for closure and approver.
Minimal-risk clearance	The system may proceed within stated conditions.	Registry ID, owner attestation, approved-use conditions, and reassessment triggers.
Limited-risk review opened	The system may proceed only through assigned limited-risk controls.	Provisional tier, required reviewers, required artifacts, target gate date, and owner.
High-risk review opened	The system may proceed only through full gate sequence.	Provisional tier, gate owners, diligence stack, Committee path, and expected timeline.
Intake hold	Prohibited-use, data-rights, vendor-evidence, security, privacy, legal, or unresolved classification issue prevents progress.	Hold reason, accountable reviewer, missing evidence, and resubmission conditions.
Controlled evaluation only	The team may run a limited evaluation with approved data and no external effect.	Evaluation scope, permitted data, environment, expiration date, monitoring owner, and prohibition on production use.
Reclassification opened	An existing system may need a new tier or control path.	Prior registry ID, change summary, new risk facts, and required review path.
Escalation opened	An incident, complaint, audit issue, or regulatory inquiry requires Annex F handling.	Incident or escalation ID, severity, owner, immediate containment decision, and linkage to registry.

Section 11

Registry Handoff

Every intake outcome except "out of scope" creates or updates a registry record. The intake workflow must pass the following fields to Annex B.

Registry field	Source in Annex A
System ID and name	Intake ID and use-case name.
Use-case owner and accountable executive	Intake metadata.
Risk tier and classification date	Provisional or final classification from routing and Annex C.
Build, fine-tune, procure status	Configuration and system description.
EU AI Act role	EU-market addendum and posture response.
Foundation model lineage	Build or fine-tune addendum and vendor evidence.
Training and input data sources	Data and evidence section.
Affected populations	System description and risk questions.
Evaluation status and results	Internal evidence, vendor evidence, and gate outputs.
Human-oversight design	System description and risk questions.
Deployment status and environments	Intake metadata and system description.
Monitoring configuration and last review	Attachment schedule and gate outputs.
Vendor and contract reference	Procurement addendum.
Linked incidents	Incident or escalation outcome.

Section 12

Source Basis and Volatility Note

This intake model aligns to NIST AI RMF Map and Govern because it identifies context, affected groups, data sources, accountability, and lifecycle ownership before the Company measures or manages risk. It aligns to ISO/IEC 42001 because it creates the documented process, ownership, evidence, and continual-improvement record an AI management system requires. It aligns to the EU AI Act because it captures intended purpose, provider or deployer posture, market placement, high-risk categories, prohibited-use indicators, transparency triggers, and material-change facts before the system is placed on a market or put into service.

The routing questions also preserve state and sector overlays. California-facing public generative AI may require training-data documentation review. NYDFS-covered institutions must evaluate AI cybersecurity risk inside the existing Part 500 framework. NYC employment tools may require AEDT bias-audit and notice review. Healthcare, patient-impact, protected-health-information, and medical-device uses require their own review path and should not remain buried inside a generic Other-sector process.

Julio Macedo Senior Attorney | AI Governance & Legal Ops jhmacal.com