Does This Project Need AI?
Does This Project
Need AI?
Most projects that get labelled "AI" do not need it, and the ones that do rarely need a model built from scratch. This is a three-part framework for deciding honestly, then sourcing, governing, and running what you actually build.
The Decision
Run a candidate through four gates, top to bottom, and stop at the first exit. The gates decide whether the project needs AI and which sourcing path it takes. Judge the system, not the team: a capability counts only if the machine performs it, not a person and not a fixed rule.
Red line
A fast legality check, not an assessment. Is the intended use prohibited or clearly unlawful? The EU AI Act's unacceptable-risk tier includes social scoring, manipulative or exploitative systems, and most real-time remote biometric identification in public spaces.
Prohibited or unlawful. No design work. The full responsible-AI assessment runs later, in Part 2, so you never assess something that exits here.
Amenability: is it AI-shaped?
Must the machine itself do at least one of these?
- Perceive — interpret messy, unstructured input (images, audio, free text, sensors)
- Predict — estimate something unstated (intent, risk, demand, likelihood)
- Plan — choose among action sequences that change with conditions
- Generate — produce novel, context-aware content (text, code, audio, images)
None of the four. The machine only executes fixed steps a human decided.
If at least one applies: are the rules too implicit to write by hand, and is probabilistic output acceptable?
Rules are writable, or you need an exact, auditable answer every time. Still not AI.
Necessity: is AI needed at all?
Would a simple heuristic or business rule get you most of the way?
Rule of thumb from Google's Rules of ML: a heuristic often gets you about half of what ML would.
Ship it, instrument the baseline KPI and error rate, and revisit AI only when it plateaus. Exception: if calling an off-the-shelf model API is genuinely faster and cheaper than building and maintaining the heuristic, skip ahead to Gate 3. The bar is "the heuristic is more work than it is worth," not "AI is available."
Sourcing: build, buy, fine-tune, or hybrid?
Decide the path here. How to walk each one is Part 2.
An existing model works as-is through prompting or retrieval (RAG). You need an evaluation set, not training data.
It is close, but needs your domain's vocabulary, tone, or format.
It fits, but regulated data must be filtered before it reaches an external model.
If nothing off the shelf fits and you must build, test data and cost:
No data. Build a simple version, instrument it, collect data, revisit.
Data exists, but lifetime cost exceeds value.
Data exists and value clears cost. Clears every gate.
The exits at a glance
| Exit | Reached when | Next |
|---|---|---|
| Stop | Prohibited or unlawful use | Do not proceed |
| Automation | No perceive / predict / plan / generate | Rules engine, RPA, script |
| Deterministic | Rules writable, or exact output required | Conventional software |
| Heuristic first | A simple rule covers most of the outcome | Ship, measure, revisit |
| Integrate / Buy | Off-the-shelf model works as-is | Part 2, Section B1 |
| Fine-tune | Needs domain adaptation | Part 2, Section B2 |
| Hybrid | Regulated data needs filtering | Part 2, Section B3 |
| Not yet | Build path, no data | Instrument, collect, revisit |
| Not worth it | Build path, cost above value | Stop or shelve |
| Build custom | Clears every gate | Part 2, Section B4 |
Gate 1 is easy to pass. Gate 2 is where over-engineering dies. Gate 3 is where 2026 projects go wrong, by assuming "we need AI" means "we must train a model."
Sourcing, Governance & Operation
Enter only after Part 1 returns an AI exit. Work Section A first, then your sourcing path in Section B, then Section C if the system acts autonomously, then Section D before and after launch. Any figures below are illustrative starting points, not standards.
Section A · Responsible AI & Data Sovereignty
Run first, because it can still stop or reshape the project, and running it after AI is confirmed means you never assess something that was never AI.
A1 · Decision sensitivity
If the system decides or materially influences outcomes about people, money, health, safety, or regulated data (hiring, credit, fraud, triage, KYC/AML, pricing, monitoring), classify it against the EU AI Act tier and run the assessment: bias and fairness testing, audience-appropriate explainability, data-subject rights, and human oversight. Anchor controls to the NIST AI RMF functions, Govern, Map, Measure, Manage.
A2 · Data sovereignty and residency
If regulated personal data would leave its jurisdiction or reach a non-regional API, resolve it first: regional or on-premises deployment, a compliant gateway, or de-identification. Check the laws that apply to you, GDPR, CCPA, UAE PDPL, DIFC Data Protection Law, Ethiopia's Personal Data Protection Proclamation, or local equivalents. Several restrict cross-border transfer absent an adequate level of protection.
Section B · Sourcing execution
B1 · Integrate / Buy
Build an evaluation set covering core and edge cases, sized to your risk. Review latency, cost at production volume, and vendor lock-in. Mitigate lock-in with a model-agnostic abstraction layer, a preference for open-weight models, and portable prompts and evaluations.
B2 · Fine-tune
Use parameter-efficient fine-tuning (LoRA or QLoRA) over full retraining in most cases. Curate high-quality instruction-response pairs; treat any volume figure as a hypothesis to validate. Confirm licensing, consent, and retention.
B3 · Hybrid orchestration
Deploy a local small language model inside your jurisdiction to classify, mask PII, and route. Send only sanitised content to a frontier model for synthesis, keeping regulated data in-boundary.
B4 · Build custom
Complete a total-cost-of-ownership view first, training and inference compute, labelling, monitoring, and any bootstrapping token costs. Stand up data pipelines and an MLOps roadmap. If hosting constraints rule out standard cloud or on-premises, continue to Part 3.
Section C · Agentic overlay
Only if the system plans or acts autonomously. An overlay on whichever path you took, not a separate path.
- Autonomy limits. Live actions without approval require interception points, full audit logging, a tested kill switch, and an adversarial safety evaluation.
- Keep it simple. A single-agent router or linear chain before any multi-agent framework.
- Integration. Prefer a standardised layer such as the Model Context Protocol over brittle custom connectors.
- Telemetry beyond accuracy. Task success, tool-call precision, steps per task, cost per run, safety-violation rate, plus a failure-mode taxonomy.
Section D · Operational readiness
- Production readiness. Score against the ML Test Score, taking your score as the lowest of its four category totals. Add content-quality, hallucination, and retrieval checks for generative systems.
- Drift and decay. Monitor data drift, concept drift, and KPI decay. AI degrades silently; uptime monitoring is not enough.
- Rollback. Keep a tested fallback to the Part 1 heuristic, with a recovery-time target matched to criticality.
- Ownership and sign-offs. Platform owns drift, the PMO owns KPI decay; model card and responsible-AI approvals complete before production.
Decentralized, Edge & Physical AI
Advanced deployment architectures, entered from the execution and operations work in Part 2, not from Part 1. Continue here only when a constraint makes standard centralized hosting impossible, prohibited, or physically hazardous. Each driver maps to one section.
Section E · Federated Learning
Triggered by a sovereignty or volume constraint, when raw data cannot be centralized even for local masking.
- Train locally where the data resides; transmit only updated weights.
- Aggregate with Federated Averaging into a global model.
- Harden with secure aggregation or differential privacy against data-reconstruction attacks.
- Budget for heavy communication overhead and complex orchestration.
Section F · Edge AI & IoT
Triggered when inference must run on constrained hardware or with intermittent connectivity.
- Large foundation models will not fit on most edge devices. Compress with quantization and pruning. Small models can run on edge directly, the local-model pattern from Section B3.
- Compile with hardware-specific toolchains and edge-optimized runtimes.
- Fail safely offline with local fallback rules.
- Ship updates through secure over-the-air pipelines; edge models drift too.
Section G · Physical & Kinetic AI
Triggered by the Section C agentic overlay, when the agent actuates physical machinery. Apply Section C's controls first; the items below are the physical-world additions.
- Validate against physical interfaces (hardware-in-the-loop), not simulation alone.
- Verify sensor fusion on contradictory signals, for example a camera that sees a clear path while LiDAR detects an obstacle.
- Enforce deterministic safety envelopes. An action outside the limits triggers a deterministic hardware interrupt that overrides the AI. This is the physical kill switch: a safety-rated function independent of the model, built to recognized machine-safety standards, not application code the model can influence.
References
Every layer past the Gate 1 heuristic is anchored to published work. Standards and the foundation-model landscape change quickly; re-check before relying on any item for a formal compliance decision.
- Google. Introduction to Machine Learning Problem Framing and Managing ML Projects: Feasibility. Google for Developers, 2025.
- Zinkevich, M. Rules of Machine Learning: Best Practices for ML Engineering. Google.
- Amazon Web Services. Machine Learning Lens (Well-Architected): ML Problem Framing.
- European Union. Regulation (EU) 2024/1689 (AI Act), risk tiers.
- NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023.
- Breck, E., Cai, S., Nielsen, E., Salib, M., Sculley, D. The ML Test Score. IEEE Big Data, 2017, pp. 1123-1132.
- Sadat, A., et al. Perceive, Predict, and Plan. ECCV 2020, pp. 414-430.
- McMahan, B., et al. Communication-Efficient Learning of Deep Networks from Decentralized Data. AISTATS 2017.
- Gholami, A., et al. A Survey of Quantization Methods for Efficient Neural Network Inference. 2021.
- Hu, E., et al. LoRA: Low-Rank Adaptation of Large Language Models (2021); Dettmers, T., et al. QLoRA (2023).
- Anthropic. Model Context Protocol, 2024.
- Machine-safety standards (Section G): IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems, Ed. 2.0, 2010; ISO 13849-1:2023; IEC 62061:2021; ISO 10218-1:2025 and ISO 10218-2:2025; ISO/TS 15066:2016 (now integrated into ISO 10218-2:2025).
- Data-protection law: UAE Federal Decree-Law No. 45 of 2021 (PDPL); DIFC Data Protection Law No. 5 of 2020; Ethiopia Personal Data Protection Proclamation No. 1321/2024.
- ISO/TS 31050:2023, Risk management: Guidelines for managing an emerging risk to enhance resilience (general emerging-risk reference complementing ISO 31000; not a machine-safety standard).
Last verified June 2026.