Enterprise AI use-case routing frameworks

Research Question

What decision frameworks do enterprises use to route Artificial Intelligence (AI) use cases to the appropriate platform, implementation pattern, and risk tier, distinguishing low-code business-led, pro-code custom, and developer productivity use cases, and what criteria, routing signals, and governance checkpoints does each routing decision require?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

• Enterprises should use a three-lane routing framework with one shared intake rubric: route low-criticality, approved-platform business automation to a low-code lane, route sensitive or deeply integrated systems to a pro-code custom lane, and route internal engineering assistance to a developer productivity lane.
• The routing decision should be driven by data sensitivity, outcome criticality, autonomy, integration depth, third-party dependency exposure, and regulatory classification rather than by vendor preference or team habit.
• A central platform team should own the shared enterprise governance layer, approved tools, and escalation rubric, and routing should follow risk signals rather than vendor-stack silos because the same platform family can host both low-risk assistance and higher-control workflows.
• The main operational risk is misrouting, because lightweight platform controls are insufficient for high-impact systems and heavyweight review is wasteful for low-risk internal assistance.

Key Findings

1. High confidence: Enterprises need one intake rubric that scores data sensitivity, impact criticality, autonomy, integration depth, and regulatory exposure before deciding which AI delivery lane a use case should enter.
2. Medium confidence: The business-led low-code lane is most defensible for approved-platform workflows where central administrators can enforce managed environments, connector guardrails, maker accountability, and rapid escalation of noncompliant apps.
3. High confidence: The pro-code custom lane should be selected when a use case depends on custom engineering, sensitive or regulated data, deep system integration, or operational controls that must span the full model and software lifecycle.
4. Medium confidence: Developer productivity AI is best treated as an internal tooling lane with enterprise policy controls, privacy decisions, and mandatory human review rather than as unattended business automation.
5. Medium confidence: The central platform team should own the shared enterprise governance layer and approved capabilities, while business or engineering teams should own route-specific implementation after the intake decision is made.
6. Medium confidence: The most reliable escalation triggers are trusted-boundary breaks, unsupervised action, production-system change, and rights-bearing decisions, because these signals consistently increase security, compliance, and operational risk across frameworks.
7. Medium confidence: The main failure modes are misrouting low-code automation into high-impact domains, forcing low-risk internal assistance through heavyweight committees, and allowing AI tools or connectors to bypass central policy settings.

Assumptions

• None.

Analysis

• The standards and regulatory sources were weighted most heavily because they define the control objectives that any routing framework must satisfy, even though they do not name the three lanes directly.
• Route-specific platform guidance was then used to map those generic objectives onto concrete control surfaces, which is why the low-code and developer productivity lanes are justified as distinct patterns rather than as mere subcases of general AI governance.
• The pro-code custom lane has the most detailed checkpoint evidence because cloud architecture frameworks describe model lifecycle, observability, CI/CD, controlled release, and post-deployment monitoring in operational detail.
• A vendor-stack-based routing alternative is weaker than risk-signal routing, because the same platform family can host both lightly governed assistance and higher-control workflows, so platform brand alone does not determine review depth.

Risks, Gaps, and Uncertainties

• Public platform documentation describes available governance levers, but it rarely publishes numeric scoring thresholds for route assignment, so each enterprise still needs to calibrate its own cutoff values.
• The AI Act identifies prohibited, high-risk, transparency, and minimal-or-no-risk categories, but enterprise intake still needs internal judgment for cases that are not explicitly named as prohibited or high risk.
• The route boundary for developer productivity tools could shift if organizations allow those tools to execute production changes autonomously, because that would move them closer to operational automation than to supervised assistance.

Open Questions

• What scoring rubric and threshold bands are most usable for a real backlog intake form across these three lanes?
• How should enterprises route AI agents that both assist developers and can execute production actions, such as deployment or support automation?
• Which evidence artifacts should be mandatory at each checkpoint for regulated sectors such as banking or healthcare?

Output

• Type: knowledge
• Description: Three-lane enterprise routing framework for AI use-case intake, including route-selection signals and governance checkpoints for low-code, pro-code, and developer productivity work.
• Links:
  • National Institute of Standards and Technology (NIST) Artificial Intelligence Risk Management Framework
  • Cloud Adoption Framework for Azure: AI governance
  • GitHub Copilot policies overview

sources

Starting points - papers, articles, videos, repos, docs.

• [x] National Institute of Standards and Technology (NIST) Artificial Intelligence Risk Management Framework — - primary governance framework for Govern, Map, Measure, and Manage functions.
• [x] NIST Artificial Intelligence Risk Management Framework (AI RMF) 1.0 Digital Object Identifier (DOI) record — - authoritative citation for core functions and trustworthy AI characteristics.
• [x] International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 42001:2023 — - Artificial Intelligence Management System (AIMS) requirements and continual-improvement framing.
• [x] European Commission AI Act overview — - official risk-tier summary, high-risk obligations, and application timeline.
• [x] Cloud Adoption Framework for Azure: AI governance — - intake risks, policy categories, enforcement, monitoring, and independent review guidance.
• [x] Microsoft AI risk assessment for Machine Learning (ML) engineers — - severity signals for sensitive data, business criticality, and production use.
• [x] Power Platform Center of Excellence (CoE) Starter Kit overview — - low-code governance model, maker enablement, and compliant-app controls.
• [x] Power Platform data loss prevention overview — - connector guardrails, design-time and runtime enforcement, and quarantine behavior.
• [x] Managed Environments for Power Platform — - supported tenant-scale controls for low-code environments.
• [x] Google Cloud Well-Architected Framework — - base control pillars for security, reliability, cost, operations, and performance.
• [x] Google Cloud Well-Architected Framework: AI and ML perspective — - AI-specific operating guidance.
• [x] Google Cloud AI and ML perspective: Operational excellence — - problem definition, versioning, observability, Continuous Integration and Continuous Delivery (CI/CD), and controlled release guidance.
• [x] Amazon Web Services (AWS) Well-Architected Framework: Machine Learning Lens — - lifecycle and route-specific machine learning design guidance.
• [x] GitHub Copilot policies overview — - enterprise, organization, feature, model, and privacy policy controls.
• [x] Managing policies and features for GitHub Copilot in your enterprise — - enterprise control surface for feature availability and enforcement.
• [x] Responsible use of GitHub Copilot inline suggestions — - human review, secure coding, and limitation guidance for developer productivity use cases.
• [x] Enterprise AI platform operating models: organisational structure and ownership — - prior completed repository work on central platform ownership and federated delivery.
• [x] Enterprise AI capability model for use-case maturity decisions — - prior completed repository work on shared capability reuse versus net-new capability building.