Introduction
AI procurement involves unique contractual considerations that differ significantly from traditional software licensing. The dynamic nature of AI systems, dependency on training data, performance variability, and regulatory complexity require specialized contract structures and provisions.
This part establishes the foundational knowledge needed to structure AI transactions, whether procuring AI services, licensing AI technologies, or engaging development partners.
💡 Key Insight
AI contracts cannot simply replicate traditional software agreements. AI systems behave probabilistically rather than deterministically, may change over time through learning, require ongoing data flows, and present novel risk allocations. Every provision must be evaluated through an AI-specific lens.
AI Procurement Models
Organizations can acquire AI capabilities through various commercial models, each with distinct contractual implications.
AI Software as a Service (SaaS)
Cloud-based AI accessed via API or web interface. Vendor hosts and maintains the AI system. Subscription-based pricing typical.
On-Premise Deployment
AI software installed on customer infrastructure. Greater control but requires internal expertise. License-based with maintenance fees.
Custom AI Development
Bespoke AI system built to specifications. Development agreement with deliverables, milestones, and IP allocation.
AI Platform/Framework
Tools and infrastructure for building AI applications. May include pre-trained models, APIs, and development environments.
Managed AI Services
Outsourced AI operations including monitoring, tuning, and maintenance. Service-level commitments with defined outcomes.
AI Component/Model License
Pre-trained model or AI component integrated into larger systems. Royalty-based or perpetual licensing.
SaaS vs. On-Premise Considerations
The choice between cloud-based and on-premise AI deployment has significant contractual implications beyond technical architecture.
| Factor | AI SaaS | On-Premise AI |
|---|---|---|
| Data Control | Data processed in vendor environment; contractual protections needed | Data remains on-premise; greater control |
| Model Updates | Vendor controls updates; may change behavior | Customer controls update timing |
| Compliance | Depends on vendor's controls; audit rights critical | Direct compliance responsibility |
| Availability | Dependent on vendor uptime; SLA essential | Internal infrastructure responsibility |
| Exit Strategy | Data portability and transition support needed | License terms govern continued use |
| Customization | Limited to vendor offerings; fine-tuning options vary | Full customization possible |
⚠ AI SaaS Data Considerations
When using AI SaaS, critically examine: (1) Will customer data be used to train or improve vendor models? (2) Where is data processed geographically? (3) What happens to data after contract termination? (4) Are there data residency options? (5) Can data be truly deleted from AI systems?
Service Level Agreements for AI
AI Service Level Agreements require metrics beyond traditional uptime guarantees. AI performance is probabilistic and context-dependent, requiring specialized SLA structures.
📋 AI-Specific SLA Metrics
- Availability: System uptime percentage (e.g., 99.9%) with defined measurement periods and exclusions
- Response Time: API latency thresholds (e.g., 95th percentile < 200ms)
- Throughput: Requests per second or concurrent user capacity
- Accuracy Metrics: Model performance on defined test sets (e.g., F1 score > 0.85)
- Error Rates: Maximum acceptable error or failure rates
- Model Drift: Performance degradation thresholds triggering remediation
- Incident Response: Time to acknowledge and resolve issues by severity
📄 Sample SLA Clause: AI Availability
⚠ AI Performance Variability
Unlike traditional software, AI accuracy metrics can be challenging to define contractually. Consider: (1) Who defines the benchmark test set? (2) What happens when real-world performance differs from benchmark performance? (3) How is accuracy measured over time? (4) What triggers remediation vs. termination?
Acceptance Criteria for AI Systems
Acceptance testing for AI systems requires different approaches than traditional software acceptance. AI outputs are probabilistic, and performance depends heavily on data quality and use case specifics.
Elements of AI Acceptance Testing
- Functional Testing: Core AI functionality operates as specified
- Performance Testing: Accuracy, latency, and throughput meet defined thresholds
- Integration Testing: AI integrates correctly with customer systems
- Bias/Fairness Testing: Model does not exhibit prohibited discrimination
- Security Testing: AI system meets security requirements
- Explainability Testing: AI provides required explanations for decisions
- Edge Case Testing: AI handles boundary conditions appropriately
For a customer service AI chatbot:
Functional: Handles all defined intent categories; escalates appropriately
Performance: 90%+ intent recognition accuracy; < 2 second response time
Integration: Correct CRM data retrieval and update
Fairness: No statistically significant accuracy differential across demographic groups
Security: Passes penetration testing; no PII leakage
Explainability: Can provide reasoning for escalation decisions
✅ Best Practices for AI Acceptance
- Define acceptance criteria before contract signature, not during implementation
- Use customer-provided test data representative of production use
- Include both automated tests and human evaluation
- Allow for iterative testing with defined remediation periods
- Establish clear pass/fail criteria (not subjective assessments)
- Consider a pilot/POC period before full acceptance
- Document all test results for future reference
Key Takeaways
- AI Contracts are Different: Probabilistic nature requires specialized provisions
- Procurement Model Matters: SaaS, on-premise, and custom development have distinct risk profiles
- Data Considerations are Central: AI contracts must address data use, storage, and rights
- SLAs Need AI Metrics: Beyond uptime - accuracy, drift, and performance thresholds
- Acceptance Testing is Complex: Must cover functionality, performance, fairness, and security
- Define Criteria Early: Acceptance criteria should be agreed before signing