A 19-person AI agency in Tampa signed a $320,000 contract to build a fraud detection system for a mid-size bank. During the sales process, everyone focused on the exciting technical work — anomaly detection, real-time scoring, integration with the bank's transaction system. Nobody asked hard questions about the data. When the team started the project and finally accessed the bank's transaction data, they discovered three critical problems: the data was spread across seven legacy systems with incompatible schemas, only 14 months of historical data was available (the model needed at least 36 months for seasonal patterns), and the bank's compliance team required that all data processing happen on-premise in their data center — something the agency had never done. The project ultimately took 11 months instead of the planned 5, cost the agency $480,000 to deliver, and generated a $160,000 loss.
Every one of those risks was identifiable before the contract was signed. A structured pre-project risk assessment would have surfaced the data fragmentation, the limited history, and the on-premise requirement during the sales process. The agency could have either priced the additional work into the contract or declined the engagement.
Pre-project risk assessment is not pessimism — it is professionalism. The agencies that systematically evaluate risks before committing to projects are the ones that consistently deliver profitably. The agencies that skip this step are the ones with war stories about projects that nearly bankrupted them.
The AI Project Risk Taxonomy
AI projects face risks across seven categories. A thorough pre-project assessment evaluates each one.
Category 1 — Data Risks
Data is the foundation of every AI project, and data risks are the most common cause of project failure.
Availability risk: Can you access the data you need? Is it stored in accessible systems? Are there technical, legal, or organizational barriers to access?
Quality risk: Is the data clean, complete, and accurate? What percentage of records have missing values? Are there systematic biases in how data was collected? How noisy is the data?
Volume risk: Is there enough data to train the model effectively? For supervised learning, do you have enough labeled examples? For rare events (fraud, equipment failure), do you have enough positive examples?
Relevance risk: Does the available data actually contain the signal needed to solve the problem? Historical data may not reflect current patterns. Proxy variables may not capture the underlying phenomenon.
Privacy and compliance risk: Does the data contain personal information subject to privacy regulations? Are there consent issues with using the data for AI model training? Are there cross-border data transfer restrictions?
Assessment questions to ask during pre-sales:
- "Can you describe your data sources, their formats, and how we would access them?"
- "How much historical data is available? How far back does it go?"
- "Has this data been used for analytics or modeling before? What was the experience?"
- "Are there any privacy, regulatory, or compliance restrictions on using this data?"
- "Can we see a sample of the data before signing the contract?"
Category 2 — Technical Risks
Complexity risk: Is the technical approach well-understood, or does it require novel research? Projects that require inventing new techniques carry fundamentally different risk than projects that apply proven methods.
Performance risk: Can the model achieve the accuracy/performance the client expects? Are the expectations grounded in reality, or are they aspirational targets that may not be achievable with the available data?
Integration risk: How complex is the integration with existing systems? Are there APIs, or will you need to build custom connectors? Are the target systems stable, well-documented, and supported?
Infrastructure risk: Can the existing infrastructure support the AI workload? Do you need to provision significant new compute or storage? Are there on-premise requirements that limit your architecture options?
Scalability risk: Will the solution need to handle scale (high transaction volumes, real-time processing, large user populations) that introduces engineering complexity beyond the core AI work?
Assessment questions to ask during pre-sales:
- "What is the target performance level for the model, and how was that target determined?"
- "What systems will this solution need to integrate with? Are there documented APIs?"
- "Where will the solution run — cloud or on-premise? Are there restrictions on the infrastructure we can use?"
- "What is the expected scale — transaction volumes, user counts, data volumes?"
Category 3 — Scope Risks
Requirements clarity risk: Are the requirements well-defined, or are they vague and likely to evolve? "Build us an AI-powered analytics platform" is a scope risk. "Build a model that predicts customer churn using CRM data" is much clearer.
Stakeholder alignment risk: Do all stakeholders agree on what the project should deliver? Conflicting visions from different departments create scope expansion pressure.
Success criteria risk: Are the success criteria measurable and agreed upon? Vague success criteria ("improve efficiency") invite scope creep because there is no objective endpoint.
Feature creep risk: Is the client likely to add requirements during the project? Clients with limited AI experience often underestimate what they need and add requirements as they learn.
Assessment questions to ask during pre-sales:
- "What specific, measurable outcomes will make this project a success?"
- "Who are all the stakeholders, and do they agree on the project goals?"
- "Have the requirements been documented and approved by the decision maker?"
- "Is this the client's first AI project, or have they done similar work before?"
Category 4 — Client Risks
Client capacity risk: Does the client have the bandwidth to support the project? AI projects require significant client involvement — data access, domain expertise, feedback, decisions. A client team that is stretched thin will cause delays.
Decision-making risk: Can the client make decisions quickly, or does every decision require multiple levels of approval? Slow decision-making extends timelines and increases costs.
Technical maturity risk: Does the client's technical team understand AI well enough to provide useful input and adopt the delivered solution? Low technical maturity means more hand-holding, more rework, and longer adoption timelines.
Organizational change risk: Will the AI solution require changes to the client's processes, roles, or workflows? Organizational change resistance is a common cause of AI project failure — not technical failure, but adoption failure.
Assessment questions to ask during pre-sales:
- "Who will be our day-to-day contact, and how much time can they dedicate to this project?"
- "How are project decisions made in your organization? Who has final approval authority?"
- "Has your team worked with AI/ML systems before? What was the experience?"
- "Will this solution change any existing workflows or processes? Have those changes been discussed with the affected teams?"
Category 5 — Commercial Risks
Pricing risk: Is the project priced correctly given the scope and risks? Fixed-price projects with significant uncertainty carry high pricing risk.
Payment risk: What is the client's payment history and financial stability? Will they pay on time?
Concentration risk: Does this project make you overly dependent on a single client? A project that represents 30%+ of your revenue creates concentration risk.
Margin risk: After accounting for all costs (including the risk adjustments you are about to calculate), does this project meet your minimum margin threshold?
Category 6 — Team Risks
Skill risk: Does your team have the specific skills this project requires? An NLP project requires different expertise than a computer vision project. Assuming skill transferability without verification is risky.
Availability risk: Are the team members you plan to assign actually available when the project starts? Or are they committed to other projects that might overrun?
Key person risk: Does the project depend on one specific individual whose departure or illness would derail the work?
Capacity risk: Do you have enough total capacity to take on this project without overloading your team?
Category 7 — External Risks
Regulatory risk: Could regulatory changes affect the project during its lifecycle? AI regulation is evolving rapidly.
Market risk: Could market changes affect the client's need for this solution?
Technology risk: Could a technology change (new model release, platform update, API deprecation) affect the technical approach?
Competitive risk: Could a competitor release a solution that makes the project unnecessary or less valuable?
The Risk Assessment Process
Step 1 — Risk Identification (60-90 Minutes)
Assemble the assessment team: the account executive (client context), a senior technical lead (technical risk evaluation), and the delivery director or operations lead (commercial and operational risk evaluation).
Walk through each risk category and ask the assessment questions. For each identified risk, document:
- Description: What is the risk? Be specific.
- Category: Which of the seven categories does it fall into?
- Trigger: What would cause this risk to materialize?
- Impact: If the risk materializes, what is the impact on the project (scope, timeline, cost, quality)?
Step 2 — Risk Scoring (30 Minutes)
Score each identified risk on two dimensions.
Probability (1-5):
- 1: Unlikely (less than 10% chance)
- 2: Possible (10-30% chance)
- 3: Moderate (30-50% chance)
- 4: Likely (50-75% chance)
- 5: Almost certain (over 75% chance)
Impact (1-5):
- 1: Minimal (less than 5% cost or schedule impact)
- 2: Minor (5-15% impact)
- 3: Moderate (15-30% impact)
- 4: Major (30-50% impact)
- 5: Critical (over 50% impact or project failure)
Risk score = Probability x Impact
Scores of 1-6: Low risk. Manageable with standard practices. Scores of 8-12: Medium risk. Requires specific mitigation actions. Scores of 15-25: High risk. Requires significant mitigation, risk pricing, or decision to decline.
Step 3 — Risk Mitigation Planning (45-60 Minutes)
For each medium and high risk, develop a mitigation plan.
Mitigation strategies:
- Avoid: Change the approach to eliminate the risk entirely. Example: If on-premise requirements are a high risk, negotiate for a cloud-based approach instead.
- Mitigate: Take actions that reduce the probability or impact. Example: If data quality is a risk, include a funded data assessment phase before committing to model performance targets.
- Transfer: Shift the risk to another party. Example: If performance uncertainty is high, use a T&M pricing model instead of fixed price, transferring the schedule risk to the client.
- Accept: Acknowledge the risk and price it into the project. Example: If there is a 30% chance of needing an additional data source, add a contingency for that cost.
Step 4 — Risk-Adjusted Pricing (30 Minutes)
Incorporate the risk assessment into your project pricing.
For each accepted risk, calculate the expected cost impact: Probability x Impact Cost.
Example: 30% probability of needing an additional 200 hours for data quality issues at $175/hour = 0.3 x $35,000 = $10,500 expected cost.
Sum all expected cost impacts and add this to your base project price as a risk contingency.
Risk contingency as a percentage of project value:
- Low-risk projects (few medium risks, no high risks): 5-10% contingency
- Medium-risk projects (several medium risks, 1-2 high risks with mitigation): 10-20% contingency
- High-risk projects (multiple high risks): 20-30% contingency or reconsider taking the project
Step 5 — Go/No-Go Decision (15 Minutes)
Based on the risk assessment, make a deliberate decision.
Go: Risks are manageable, mitigations are in place, and the project is priced to account for risk.
Go with conditions: The project is viable but only if specific conditions are met — data access confirmed before contract signing, on-premise requirement removed, client commits to a dedicated point of contact, etc.
No-go: Risks are too high, mitigations are insufficient, and the potential downside exceeds the potential upside. Walking away from a bad project is one of the most profitable decisions an agency can make.
Embedding Risk Assessment in Your Sales Process
Risk assessment should not be a separate, isolated exercise. It should be woven into your sales process.
During qualification: Ask enough questions about data, technology, and client readiness to identify obvious red flags. High-risk projects should be flagged early so resources are not wasted on proposals and negotiations for deals you will ultimately decline.
During scoping: The scoping process is a natural opportunity to assess risks in detail. As you define scope and deliverables, identify the assumptions and dependencies that create risk.
During proposal: Include a risk section in your proposal that transparently communicates the risks you have identified and how you plan to mitigate them. This demonstrates professionalism, manages client expectations, and justifies your contingency pricing.
Before contract signing: Conduct the formal risk assessment (Steps 1-5 above) before signing the contract. This is your last opportunity to adjust pricing, scope, or terms based on risk, or to walk away.
Building a Risk Knowledge Base
Over time, your risk assessments become a valuable knowledge base.
Post-project risk review: After every project, compare the risks you identified pre-project against the risks that actually materialized. Which risks were overestimated? Which were underestimated? Which risks were not identified at all?
Risk calibration: Use historical data to calibrate your probability and impact scores. If you consistently rate data quality risk as probability 2 but it materializes 60% of the time, your scoring needs adjustment.
Pattern recognition: After 15-20 completed risk assessments, patterns emerge. Certain industries, project types, or client profiles consistently produce specific risks. Use these patterns to inform future assessments.
Risk register template: Maintain a standard risk register with pre-populated risks for common project types. When starting a new assessment, begin with the template and customize based on the specific project.
Your Next Step
Conduct a risk assessment on your next project opportunity before signing the contract. Use the seven-category framework and the five-step process described above. Even an informal assessment — an hour of structured discussion with your sales and technical leads — will surface risks that might otherwise be discovered mid-project when they are expensive to address. After completing the assessment, calculate the risk-adjusted price and compare it against your original estimate. The difference is the cost of the risk you were planning to absorb unknowingly. Build this into your price or your contingency budget. Then, after the project completes, conduct a post-project risk review. Compare what you predicted against what actually happened. This feedback loop is how your risk assessment capability improves over time, and how your agency stops being surprised by problems that were predictable all along.