On a Monday in May 2026, Procurement at a Fortune-500 healthcare company signed off on a new SaaS contract for "intelligent meeting summaries." On Tuesday, Engineering pushed a fine-tuned LLM into production for an internal triage queue. On Wednesday, a Marketing team in Berlin enabled a generative-image add-on that had quietly appeared inside their Adobe seat. On Thursday, a Data Science squad inside the Claims org deployed a no-code Snowflake Cortex pipeline against a member-eligibility table. By Friday, the Responsible AI Officer's AI use inventory was already four entries out of date, and none of the four would have surfaced through procurement's standard SaaS approval flow, because the systems are not "AI tools" in their contractual descriptions; they are AI features bolted onto tools that were procured for something else. This is the shadow-AI problem, and the AI intake form is the only thing that catches it before it lands on the regulator's letter. This lesson is how to design that form: fourteen fields, six failure modes, and the integration into the AI use inventory, the tiering memo, the FRIA backlog, and the ISO/IEC 42001 A.6 evidence pack.

The Shadow-AI Problem in 2026 - Why the Intake Form Has To Exist

By May 2026, every Fortune-2000 enterprise has at least four shadow-AI ingress paths that the original procurement-and-engineering workflows were not built to catch. They are predictable, recurring, and largely invisible to a vendor-management spreadsheet that pre-dates the EU AI Act. The Responsible AI Officer who has not mapped them is governing a portfolio they cannot see.

Ingress path one, procurement adds SaaS without flagging AI. The standard procurement intake asks about data residency, security posture, SOC 2 Type II, sub-processors, and contract value. It does not ask "does this product use AI?" because in 2022 that question was unhelpful (everything used "AI") and in 2026 it is unhelpful in a different way (everything uses AI, but the deployer-side EU AI Act obligations depend on what kind). The result: a customer-relationship platform with embedded GPT-4o-class summarization, a learning-management system with embedded recommender models, and a video-conferencing tool with embedded transcription and "sentiment indicators" all sail through procurement without an AI Officer touchpoint.

Ingress path two, engineering deploys without AI Officer review. An engineering team picks up a model from Hugging Face, runs it on internal GPUs, and exposes an internal API endpoint. They did not buy anything, sign a contract, or pass through procurement. The Responsible AI Officer's standard intake, anchored on procurement, never fires. The system enters production and may not be inventoried for months. If the use case touches Annex III §4 (employment), §5(b) (creditworthiness), or any Article 5 prohibited surface, the organization is already operating outside the law.

Ingress path three, vendor adds AI features post-procurement. The procurement contract was signed in 2023. The vendor pushes a v8.2 release in Q2 2026 that adds a generative-content composer, a predictive-prioritization engine, and a chatbot wrapper. None of those features were in the contract. None of them triggered a new SaaS approval. They appear inside the existing tenant on the next Tuesday. This is the most common 2026 ingress pattern, and it is the one procurement cannot block because the contract is already in force.

Ingress path four, data-science teams build internal AI without going through governance. A Snowflake Cortex pipeline, a Databricks AutoML run, a Vertex AI notebook, a fine-tuning job on a managed inference endpoint. The team treats the model as "an analysis," not "a deployment." It is, in fact, a deployment under Article 3(1) the moment its inferences influence a business decision. The team did not know that. The intake form is how the organization makes the knowledge structural rather than tribal.

The form's job is to catch every AI deployment at the moment it enters the portfolio: not at production, not at inventory entry, but at intent to deploy or evaluate. That moment is upstream of contract signing, upstream of engineering ticket creation, and upstream of any vendor feature flag. If the form fires only at production-readiness, shadow AI has already won: the system is in use, the data has flown, the deployer-obligation clock has started, and the regulator's letter is in transit.

The form has a second job that organizations underrate: it is the L1 educational tool for the entire workforce. A well-designed intake form teaches the requester, at the moment of submission, that AI deployment carries regulatory weight, that Article 5 is a hard stop, that GPAI dependencies trigger upstream-vendor diligence, and that Annex III categories carry FRIA obligations. The form is, in effect, part of the Article 4 literacy program.

The Fourteen Fields - Anatomy of an Intake Form That Holds Up

The design problem is the one every regulatory questionnaire faces: too few fields catches names but misses the load-bearing classification triggers; too many fields and intake fatigue sets in, submissions stop, and the shadow returns. Fourteen fields is the equilibrium point we recommend for L1-L2 maturity programs in 2026: enough to fire every gate that matters under the EU AI Act, ISO/IEC 42001:2023 Annex A, NIST AI RMF Map function, NYC LL 144, Texas TRAIGA HB 149, and Colorado SB 24-205's successor SB 189, while still being completable in under fifteen minutes by a non-specialist requester with vendor documentation in hand. Each field is anchored to a specific regulatory or standards obligation that the intake form alone can catch at the gate.

Field 1 - System Name and Business Owner

A canonical name plus the named business owner (job title + name + email) accountable for the system's purpose. The auditor uses this to identify the asset; the AI Officer uses it to escalate a control finding. The pitfall: "TBD" or "Engineering team", both unacceptable. The form should refuse submission without a named human. If the requester is the business owner, they sign their own name; if submitting on behalf of someone else, that someone else countersigns within five business days. Without a named owner the system has no operational accountability, and the ISO 42001 clause 5.3 organizational-role assignment fails on inspection.

Field 2 - Purpose / Use Case (Free Text + Categorical)

A free-text description of the use case (what is the AI deciding, suggesting, or generating, and for whom?) paired with a categorical taxonomy aligned to the Annex III high-risk categories plus a "none of the above" branch for limited and minimal-risk. The categorical taxonomy must include: biometrics; critical infrastructure; education or vocational training; employment, workers' management, or candidate evaluation; credit, insurance, or essential-services decisioning; law enforcement; migration/asylum/border; justice or democratic-process influencing; transparency-only (chatbot, synthetic content, deepfake, emotion/biometric category notice); productivity or general-purpose assistance with no decisioning; analytics with no individual-level decisioning. The free-text plus categorical pairing exists because the categorical alone can be gamed ("we're not employment-related" when the system ranks candidates) and the free-text alone is unprocessable at scale. Together they triangulate.

Field 3 - Vendor (or "Internal Build")

The vendor's legal name, the product name, the product version, the URL of the most recent published model card or system card, and a checkbox: "internal build, no external vendor." Internal builds route into a separate sub-form for in-house model documentation (the lesson on writing a model card for an internally fine-tuned LLM is L2.Ch3). External-vendor submissions route into the vendor-AI due diligence questionnaire (L3.Ch8). The vendor name plus version is also what the Annex IV technical-file work links to when the system is high-risk: the deployer's file must trace the provider's identity, model identifier, and date of release.

Field 4 - Model and Version (Foundation-Model Identifier Where Applicable)

The model family and version actually in use, not "GPT" but "GPT-4o-mini, v2026-03-15"; not "Claude" but "Claude Opus 4.7 (1M context)"; not "Llama" but "Llama-3.1-70B-Instruct fine-tune, internal checkpoint #2419." For wrapped products (a SaaS that uses a foundation model internally), the form asks for both the wrapper version and the underlying model. The intake form is the only artifact in the L1 program that captures the foundation-model identifier reliably at the gate; the AI inventory schema (next lesson, 020) inherits this field directly. Without it, the GPAI exposure map is unbuildable, the Article 53 signatory check is impossible, and Annex XII upstream-documentation flow-down is unverifiable.

Field 5 - Training-Data Summary (High Level)

A two-to-five-sentence description of what data the model was trained on at the foundation-model layer, plus what additional data the deployer used for fine-tuning or retrieval-augmentation. For a closed-weights commercial model the requester pastes the vendor's Article 53(1)(d) public training-data summary URL. For an internal fine-tune the requester names the dataset (a SharePoint folder, a customer-support log dump, a public-record extract). The point is to record what the deployer knows. Where the deployer knows nothing, the form forces an explicit "unknown" and triggers a vendor-diligence task. "Unknown" is acceptable; missing is not. This field also seeds Article 10 data-governance work for high-risk systems and Article 27 FRIA evidence for the public-bodies and §5(b)/§5(c) deployers.

Field 6 - GPAI Dependency and Article 53 Signatory Status

Does the system depend on a general-purpose AI model (GPAI)? If yes: which model, which provider, and is the provider a signatory to the GPAI Code of Practice? The Article 53 signatory check matters because it determines the deployer's diligence burden. A system built on a signatory's model (the May 2026 signatories include OpenAI, Anthropic, Google DeepMind, Microsoft, IBM, Cohere, Mistral, Amazon, and Meta on the inference-API tier) inherits a presumption-of-conformity pathway under the Commission's Aug 2026 guidance. A system built on a non-signatory's model (xAI Grok, certain open-weight checkpoint redistributors, and any provider that has not signed by Aug 2, 2026) requires the deployer to produce more diligence evidence on its own: Annex XII documentation, the Article 53(1)(c) copyright policy review, and the Article 53(1)(d) public training-data summary review must be assembled from the public record rather than inherited. The intake form must capture the signatory check at the gate; downstream remediation is twenty times more expensive than catching it on submission.

Field 7 - Risk-Tier Classification Trigger (Article 5 / Article 6 / Annex III §)

A guided yes/no sequence walking the requester through the EU AI Act tiering ladder. Question one: "Does the system perform any of the eight Article 5 prohibited practices? (subliminal manipulation; exploitation of vulnerabilities; social scoring; predictive policing; untargeted facial-image scraping; workplace or education emotion recognition; biometric categorization to deduce protected attributes; real-time remote biometric identification.)" A "yes" routes immediately to the AI Officer's stop-deployment queue. Question two: "Is the system a safety component of, or itself, a product covered by harmonized Union legislation listed in Annex I, subject to third-party conformity assessment?" A "yes" routes the submission into the Annex I high-risk track (Aug 2, 2028 applicability under Omnibus VII). Question three: "Does the system fall within one of the eight Annex III categories?" with the categories enumerated and a brief plain-English description per category. A "yes" routes the submission into the Annex III high-risk track (Dec 2, 2027 applicability under Omnibus VII). Question four: "If Annex III applies, does the Article 6(3) narrow-task carve-out apply?" with the four conditions enumerated and the explicit warning that profiling forfeits the carve-out. Question five: "Does Article 50 apply: does the system interact with natural persons, generate synthetic content, deploy emotion recognition or biometric categorization, or generate deepfake content?" The intake form is not a substitute for the tiering memo (lesson 002), but it captures the first-pass classification at the gate so that the AI Officer's review is starting from a draft, not a blank page.

Field 8 - Deployer Obligations Triggered (Article 26 + Article 4)

The deployer-specific obligation set under Article 26, instructions-for-use compliance, monitoring during operation, log retention (Article 26(6)) for at least six months, suspension of use where serious risk is identified, cooperation with market surveillance, plus the Article 4 literacy population the deployment will affect. The literacy field asks: "Which staff need AI literacy training as a direct consequence of this deployment? (Operators; persons subject to the system's outputs; managers signing off on use.)" The form auto-cross-references the answer with the Article 4 literacy curriculum. If a population is not covered, the form raises a literacy-gap ticket alongside the intake. This field prevents the "we deployed it but never trained anyone" finding that surfaced in three early 2026 Member State market-surveillance audits.

Field 9 - Article 27 FRIA Trigger

Does the deployment require a Fundamental Rights Impact Assessment under Article 27? The trigger conditions: (i) the deployer is a public body or provides public services; (ii) the system is Annex III §5(b) creditworthiness or §5(c) life/health insurance; (iii) the system is in any other Annex III category and the deployer chooses to perform a FRIA voluntarily; (iv) national law or the Member State of deployment adds additional FRIA-triggering categories. The form asks each trigger as a separate yes/no, then summarizes whether a FRIA is required. A "yes" routes the submission into the FRIA backlog (with the FRIA-drafting playbook from L3.Ch2). The FRIA must be conducted before the system goes into use, the intake form is the gate that catches this in time.

Field 10 - Article 50 Disclosure Trigger

Four separate yes/no questions, one per Article 50 sub-article: (1) Does the system interact directly with natural persons such that they may not realize they are interacting with an AI? (Article 50(1) chatbot disclosure.) (2) Does the system generate synthetic audio, image, video, or text? (Article 50(2) machine-readable marking; the Omnibus VII-accelerated Dec 2, 2026 obligation.) (3) Does the system perform emotion recognition or biometric categorization (outside any Article 5 prohibition)? (Article 50(3) deployer-side notice to natural persons.) (4) Does the system generate or manipulate image/audio/video content that constitutes a deepfake, or text intended to inform the public on matters of public interest? (Article 50(4) deepfake disclosure plus public-interest text disclosure.) Article 50 stacks on top of high-risk, a system can be both Annex III high-risk AND Article 50-limited. The form must allow multiple disclosure triggers to be marked simultaneously.

Field 11 - Article 4 Literacy Population

This field is distinct from field 8 because Article 4 literacy applies regardless of risk tier, even minimal-risk and out-of-scope-but-AI-adjacent systems carry a literacy obligation for the operators and affected persons. The field asks: (a) what populations interact with the system as operators (engineers, business users, customer-facing staff); (b) what populations are subject to the system's outputs (employees, candidates, customers, citizens); (c) what populations make decisions informed by the system's outputs (managers, underwriters, compliance staff). For each population the form confirms coverage in the literacy curriculum. The literacy module for population X must have content that addresses the system's risk profile, a hiring tool's literacy content is different from a chatbot's literacy content, and the form forces that match.

Field 12 - ISO/IEC 42001 A.6.1.1 + A.6.2 Impact-Assessment Trigger

ISO/IEC 42001:2023 Annex A control A.6.1.1 (AI impact assessment) requires the organization to assess the potential consequences for individuals, groups of individuals, and societies, of the deployment of the AI system. Control A.6.2 (AI system impact criteria) requires the organization to define and document the criteria used in the impact assessment. The intake form's field 12 asks: "Has an A.6.1.1 impact assessment been performed for this system? If yes, link to the assessment. If no, the system is queued for assessment with [target date]." The form auto-applies the A.6.2 criteria: the same Article 5 / Article 6 / Annex III / Article 50 ladder used in field 7, plus impact dimensions for vulnerable populations, irreversibility of decisions, scale of affected persons, and reversibility of outputs. The intake form is the A.6.2 application; the downstream impact-assessment artifact is the A.6.1.1 record. ISO 42001 stage-2 auditors will ask for both, and the intake form is what proves the criteria were applied consistently at the gate.

Field 13 - Substantial-Modification Change-Control Gate (Article 25(1)(b) + Article 43(4))

Is this submission a brand-new deployment, or is it a modification of a system already in the inventory? If a modification, the form asks the substantial-modification questions per Article 43(4) and the Commission's substantial-modification guidance: (i) Does the modification change the intended purpose? (ii) Does the modification change the risk profile to the extent that the previous conformity assessment is no longer valid? (iii) Does the modification involve a new GPAI dependency or a foundation-model swap? (iv) Does the modification add a feature that crosses into a new Annex III category? A "yes" on any question routes the submission as a substantial modification requiring fresh conformity assessment per Article 43(4), and triggers Article 25(1)(b) provider-status review if the deployer's modification rises to the level of becoming a provider in its own right. This field is the failure point in 2025-2026 enterprise programs: most have a procurement intake but no modification-detection workflow, so a vendor v8.2 release that adds a generative module slips into the same inventory row as v7.0 and the conformity assessment that covered v7.0 is silently invalidated. The intake form's modification branch is the only structural defense.

Field 14 - Review Cadence and Next Review Date

Two parts: (a) the review cadence, monthly, quarterly, semi-annually, or annually, chosen based on tier (high-risk: quarterly minimum; limited: semi-annually; minimal: annually); (b) the explicit next-review date written into the inventory record. The cadence must align with the post-market monitoring program (Article 72 for high-risk) and the ISO 42001 clause 9.3 management-review cycle. The form auto-populates the next-review date from cadence plus submission date. The reviewer is the named business owner from field 1, with the AI Officer as backup. Without the cadence field, intake becomes a one-time event rather than a living governance loop.

Process Design - Web Form, Spreadsheet, or Governance Platform?

Three implementation patterns dominate enterprise practice in 2026, each with different cost, audit-readiness, and integration profiles.

Pattern A - Web form with backing database. A custom-built or low-code (Jira Service Management, ServiceNow, Power Apps, Workday Extend, Asana Forms) intake form posting into a backing table. Cost: low to medium; ten-day stand-up. Audit-readiness: high if the schema enforces the regulatory citations. Integration: ServiceNow integrates with most CMDB and asset-management tooling; Jira integrates with engineering workflow. Pitfall: the form becomes a glorified ticket queue without a structured tiering decision; the AI Officer ends up classifying tiers in free-text comments. Mitigation: enforce the field schema in the form definition and require field 7's tier decision as a structured selection.

Pattern B - Spreadsheet plus shared form. A Google Form or Microsoft Form posting into a shared spreadsheet. Cost: trivial; same-day stand-up. Audit-readiness: low without disciplined operating practice; the spreadsheet becomes the audit's worst nightmare within six months as multiple owners edit cells, copy rows, and rename columns. Acceptable as a transitional artifact during the first 90 days of the L1 sprint while a more durable platform is being procured. Not acceptable as a long-term solution for any organization above 1,000 employees or in any regulated sector.

Pattern C - Governance-platform integration. A purpose-built AI governance platform (Credo AI, Holistic AI, Modulos, Trustible, Saidot, Diligent ESG-AI, Salesforce AI Trust Layer, Microsoft Purview AI Hub) where the intake form is one component of a broader inventory-plus-policy-plus-audit-trail capability. Cost: high (typically €50k-€500k annual depending on scope); 60-to-120-day implementation. Audit-readiness: highest: the platform vendors design specifically against EU AI Act, ISO 42001, NIST AI RMF, and the major U.S. state laws, and produce the audit artifacts directly. Integration: deep, including procurement, model inventory, FRIA tooling, and ISO 42001 evidence packs. The pitfall: organizational change-management; without an AI Officer with mandate, the platform becomes shelfware. The mitigation: tie platform adoption to a board-approved AI risk function with quarterly metrics reporting.

Our recommendation for the L1-L2 maturity tier: start with Pattern A (a properly designed ServiceNow or Jira form with the fourteen fields and routing rules built in), move to Pattern C within twelve to eighteen months as the inventory grows past one hundred systems and the audit cadence reaches quarterly. Avoid Pattern B beyond ninety days, migration cost grows non-linearly with inventory size, and the audit-finding cost of an unstructured spreadsheet exceeds the platform cost within a single audit cycle for most regulated enterprises.

Routing Rules - Where Submissions Go After the Form Posts

An intake form that catches a submission but routes it nowhere is theater. The form must trigger four parallel workflows, each with a named owner, an SLA, and an escalation path. The four routings should be explicit in the form's logic, not derived after submission by manual triage.

Routing 1 - AI Officer review queue. Every submission lands in the Responsible AI Officer's queue regardless of tier. The AI Officer's first-pass review confirms the tier classification, validates the GPAI dependency, signs off on the Article 5 negative-assurance attestation, and either approves the submission for the next routing step or escalates. SLA: five business days for limited and minimal-risk; ten business days for high-risk; immediate for any Article 5 prohibited trigger.

Routing 2 - Business-unit owner sign-off. The named business owner (field 1) receives a counter-signature request acknowledging operational accountability for the system's purpose, the Article 26 deployer obligations (operator training, log retention, monitoring), and the next-review commitment. SLA: ten business days. Without business-owner counter-signature, the system cannot enter production. This is the routing that catches the "I just submitted it for my colleague" pattern that hides accountability.

Routing 3 - Specialized review queues based on tier. High-risk Annex III submissions route into the FRIA backlog (if applicable) and the Annex IV technical-file workstream. Article 50 submissions route into the transparency-disclosure copy queue (the legal writing team that drafts the user-facing notices). GPAI-dependent submissions route into the upstream-vendor-diligence queue (the team that builds and maintains the Annex XII upstream documentation flow-down). Article 5 prohibited triggers route into the AI Governance Committee for immediate stop-deployment review.

Routing 4 - Escalation to AI Governance Committee for high-risk and ambiguous cases. Any submission flagged high-risk, any submission with an Article 5 trigger (even if the trigger turns out to be a false positive on review), and any submission where the AI Officer's tier-classification confidence is below 80% routes to the AI Governance Committee for review at its next meeting. The committee's quorum cadence (typically bi-weekly for an active program; monthly for steady-state) determines the maximum waiting time. The committee's decision is recorded in the intake submission record and travels with the system through its lifecycle.

Integration - How the Intake Form Feeds the Rest of the L1-L5 Stack

The intake form is the first hop in a longer pipeline. Every field maps to a downstream artifact, and the form's value is proportional to how cleanly the downstream artifacts inherit its data without re-keying. Six integration points define a mature L2 program.

Integration 1 - AI use inventory (lesson 020). Fields 1, 3, 4, 6, 7, 8, 14 populate the inventory's primary record. The inventory's schema is, by design, a superset of the intake form so the data flows in without translation. The inventory becomes the registered source-of-truth that the AI Officer, the audit committee, the General Counsel, and the notified body all read from. The lesson on AI Model Inventory Schema (next, 020) defines the schema columns and the inheritance rules.

Integration 2 - Tiering memo (lesson 002). Field 7's risk-tier classification draft becomes the first row of the tiering memo. The AI Officer's review (Routing 1) confirms or revises the tier and produces the rationale paragraph. The tiering memo is the auditable artifact; the intake form is the upstream capture. ISO 42001 A.6.2 sits at the tiering-memo layer, with the intake form as the input record.

Integration 3 - GPAI exposure map (lesson 003). Field 6's GPAI dependency populates the GPAI exposure map: the matrix of which deployer systems depend on which foundation models, which providers, and which signatory-status profiles. The exposure map is what Procurement uses for vendor renegotiation, what the General Counsel uses for Article 53 contract-flow-down compliance, and what the AI Officer uses for systemic-risk scenario planning.

Integration 4 - FRIA backlog (lesson 044-048). Field 9's FRIA trigger populates the FRIA backlog. Submissions that trigger a FRIA must complete the FRIA before going into use; the intake form's date-stamp is what proves the FRIA was performed in time. The Article 27 FRIA notification to the national supervisory authority (lesson 048) cites the intake date as part of the evidence package.

Integration 5 - ISO 42001 A.6 evidence pack (lesson 056-058). Field 12's A.6.1.1 / A.6.2 triggers populate the ISO 42001 management-system evidence. Stage-2 ISO 42001 auditors will sample intake submissions and trace them through to the impact-assessment artifacts; the intake form's structured fields are what makes the trace possible without re-investigation per system.

Integration 6 - Article 4 literacy program (lesson 033-035). Field 11's literacy-population data feeds the literacy curriculum's coverage report. The literacy program reports quarterly on the percentage of identified populations that have completed the required modules; the intake form's coverage data is what makes the denominator accurate. Without the intake form, the literacy program reports a percentage that may bear no relation to actual coverage of the AI portfolio's operators and affected persons.

Six Mistakes - And How to Catch Them Before the Auditor Does

Mistake 1 - Too Few Fields (Catches Names But Not GPAI Dependency)

The most common early-program failure: the form has three fields, system name, vendor, business owner, producing a tidy list that catches nothing of regulatory substance. The audit-committee question that exposes this: "For each of these 47 systems, which foundation model does it depend on, and is the provider a GPAI Code of Practice signatory?" The answer is silence. Fix: rebuild to the fourteen-field baseline before the next quarter's reporting cycle. Migration cost is recoverable; the audit-finding cost of an unstructured inventory is not.

Mistake 2 - Too Many Fields (Intake Fatigue Stops Submissions)

The opposite failure: forty-seven fields, two-hour completion time, demands attachment of a model card, system card, datasheet, SOC 2 report, and security review, and asks the requester to certify compliance posture across eleven control frameworks. The result: requesters stop submitting. The shadow returns. Fix: the fourteen-field baseline. Heavier artifacts (model card review, SOC 2 review, security review) live in the downstream workflows triggered by intake, not in the form itself. The intake is the trigger; the workflows are the work.

Mistake 3 - No Article 5 Prohibited Check (Lets Prohibited Practices Through)

The intake form does not ask the Article 5 question, or asks it but does not enforce the answer. A workplace emotion-recognition tool, a manipulative-engagement feature, a biometric-categorization camera enters the inventory as "limited-risk" or "minimal-risk" and the organization is operating outside Article 5 from day one. Penalty exposure: Article 99(2), up to €35M or 7% of global turnover. The fix: field 7's question one is a mandatory routing gate. A "yes" answer cannot proceed past the form; it lands in the AI Officer's immediate-review queue with deployment blocked until cleared. The negative-assurance attestation on the eight sub-paragraphs (Article 5(1)(a) through 5(1)(h)) is captured as a structured field, not free text, so the AI Officer can verify each sub-paragraph was considered.

Mistake 4 - No GPAI Signatory Check (Misses Non-Signatory Diligence Burden)

Field 6 is present but the signatory check is not. The form captures "OpenAI GPT-4o" or "xAI Grok-3" but does not ask whether the provider has signed the GPAI Code of Practice. The deployer assumes presumption-of-conformity for both, which is wrong for the non-signatory. The audit finding lands six months later when the Annex XII upstream documentation is requested and the deployer has nothing because they assumed the vendor would deliver it. The fix: field 6 includes a structured "Code of Practice signatory? Yes / No / Unknown" field, with the signatory list maintained as a reference in the form's metadata and refreshed monthly as new signatories are added (or, occasionally, withdraw).

Mistake 5 - No Substantial-Modification Trigger (Loses Change-Control Coverage)

The intake form catches new deployments but does not catch modifications to existing deployments. The vendor v8.2 release with the generative module slips into production without a fresh conformity assessment. The deployer's Annex IV technical file for v7.0 is silently invalidated. Article 43(4) substantial-modification obligations are not triggered. The fix: field 13's modification branch is mandatory for any submission referencing an existing inventory row, and the form's intake workflow is connected to the inventory so that vendor-update notifications (a vendor's release notes feed, a procurement contract amendment, a security advisory) auto-create an intake submission asking the business owner whether the change is substantial.

Mistake 6 - Static Form (No Quarterly Refresh as the Regulation Evolves)

The intake form was built in Q3 2025, before Omnibus VII was even drafted. It still references the Aug 2, 2026 stand-alone Annex III applicability date. It does not capture the Dec 2, 2026 Article 50(2) accelerated marking obligation. It does not include Texas TRAIGA HB 149 as a U.S. overlay. It does not include the May 2026 Colorado SB 189 replacement. The form is out of date the moment it is published, and stays out of date because nobody owns its content. The fix: the AI Officer owns the intake form schema with a quarterly refresh cadence tied to the EU AI Act, ISO 42001, NIST AI RMF, NYC LL 144, Texas TRAIGA, Colorado SB 189, and the GPAI Code of Practice signatory list. The form's version is captured on each submission, so historic submissions can be re-evaluated against the current schema during quarterly review.

Aligning the Intake Form with ISO 42001 A.6 and NIST AI RMF Map

ISO/IEC 42001:2023 Annex A control A.6.1.1 (AI impact assessment) and control A.6.2 (AI system impact criteria) are the two controls most directly satisfied by a well-designed intake form. A.6.1.1 expects the organization to assess the potential consequences for individuals, groups, and societies of the AI system's deployment. The intake form's fields 2, 5, 7, 9, 10, 11 collectively constitute the inputs to that assessment; the AI Officer's downstream review produces the formal A.6.1.1 record. A.6.2 expects the organization to define and document the criteria used in the impact assessment. The intake form is the A.6.2 instrument, the form's field structure and its embedded routing rules are the criteria. The form's schema document, with version history and quarterly-refresh log, is what the ISO 42001 stage-2 auditor will inspect to confirm A.6.2 conformance.

NIST AI RMF 1.0 Map function, specifically Map 1 (context is established and understood) and Map 2 (categorization of the AI system is performed), is similarly satisfied by the intake form. Map 1's expectation that the organization understands the AI system's intended purpose, the deployment context, the affected populations, and the foundational technology is met by fields 2, 4, 5, 8, 11. Map 2's expectation that the system is categorized per its intended use and contextual risk is met by field 7's tiering ladder. Write the intake form once; cite it three times, EU AI Act gate, ISO 42001 A.6 evidence, NIST AI RMF Map artifact. The dual-citation pattern from the tiering memo applies again. Audit cost goes down. Documentation drift goes down. Regulator surprise goes down.

A Ninety-Day Rollout Plan for the Intake Form

The intake form rolls out in three thirty-day phases. Phase one (days 1-30): design and pilot. The AI Officer assembles the fourteen-field schema, builds the form in ServiceNow / Jira / Workday Extend, defines the four routing rules, and pilots with three friendly business units (typically a marketing team that procured a generative tool, an engineering team that built an internal model, and an HR team evaluating a recruiting vendor). The pilot generates ten to twenty submissions and exposes friction: unclear fields, misfiring routing rules, downstream workflows that do not receive the data. Iterate.

Phase two (days 31-60): organizational launch. The form goes enterprise-wide with a kick-off communication from the CIO or Chief AI Officer, mandatory training for procurement and engineering leads, and a hard requirement that no AI deployment proceeds without an intake submission. A back-fill sprint runs in parallel, the AI Officer's team works with each business unit to back-fill records for AI systems already in production, treating each back-fill as a fresh intake routed through the full workflow. Expect twenty to fifty shadow-AI systems surfaced in the first month at a typical Fortune-2000.

Phase three (days 61-90): governance integration. The form connects to the AI use inventory, the tiering memo, the FRIA backlog, the GPAI exposure map, and the ISO 42001 A.6 evidence pack. Quarterly review cadence is established. The AI Governance Committee receives its first monthly intake-summary report. The audit committee receives its first quarterly briefing with the shadow-AI catch rate, high-risk submissions, Article 5 negative-assurance attestation count, and FRIA backlog state. By day 90 the form is operational, the inventory back-filled, the AI Officer has a defensible artifact for the next regulator engagement, and shadow AI is shrinking as a structural problem.

Key Takeaways

• Shadow AI has four ingress paths in 2026. Procurement adds SaaS without flagging AI; engineering deploys without AI Officer review; vendors add AI features post-procurement; data-science teams build internal AI without governance. The intake form must catch all four at the moment of intent to deploy.
• Fourteen fields is the equilibrium point. System name + owner, purpose / use case, vendor, model + version, training-data summary, GPAI dependency + Article 53 signatory, risk-tier classification trigger, deployer obligations, Article 27 FRIA trigger, Article 50 disclosure trigger, Article 4 literacy population, ISO 42001 A.6.1.1 + A.6.2 trigger, substantial-modification change-control gate, review cadence.
• Each field anchors to a specific regulatory or standards obligation. Field 6 catches the GPAI signatory check that Procurement misses. Field 7 walks the Article 5 / Article 6 / Annex III / Article 50 ladder. Field 9 catches FRIA triggers. Field 13 catches substantial modifications that invalidate prior conformity assessments.
• Process design matters. ServiceNow / Jira backed form at L1-L2; spreadsheet acceptable only as a 90-day transitional artifact; governance-platform integration (Credo AI, Holistic AI, Modulos, Trustible, Saidot) at L3+ as the inventory grows past one hundred systems.
• Routing is non-negotiable. Every submission routes to the AI Officer queue, the business-unit owner for counter-signature, the specialized tier-based review queue, and the AI Governance Committee for high-risk and ambiguous cases.
• Integration into the L1-L5 stack is what makes the form load-bearing. Intake feeds the AI use inventory, the tiering memo, the GPAI exposure map, the FRIA backlog, the ISO 42001 A.6 evidence pack, and the Article 4 literacy program.
• Six mistakes to avoid. Too few fields (misses GPAI dependency); too many fields (intake fatigue); no Article 5 check (lets prohibited practices through); no GPAI signatory check (misses non-signatory diligence); no substantial-modification trigger (loses change-control coverage); static form (no quarterly refresh as articles evolve).
• The form is part of the Article 4 literacy program. Every submission teaches the requester that AI deployment is regulated, that Article 5 is a hard stop, that GPAI dependencies trigger upstream diligence, and that Annex III categories carry FRIA obligations. The form, in effect, distributes governance knowledge across the workforce.
• The intake form is the A.6.2 instrument under ISO 42001. The form's field structure and routing rules are the impact-assessment criteria; the schema document with version history is the audit evidence.
• Ninety days is enough for a real rollout. Days 1-30: design and pilot with three friendly business units. Days 31-60: enterprise launch with mandatory back-fill of existing AI deployments. Days 61-90: integration into the broader L1-L5 stack and the first audit-committee briefing. By day 90 shadow AI is a shrinking structural problem rather than a recurring crisis.