4.1 Ideation & Chartering
Every AI product begins with an idea—but most AI ideas never deliver value. The Ideation & Chartering phase filters opportunities through business value, technical feasibility, and ethical appropriateness screens before committing significant resources. This disciplined front-end prevents the waste of building AI solutions in search of problems.
By the end of Ideation & Chartering, you should have: (1) a validated business opportunity, (2) confidence that AI is the right solution, (3) a completed Model Card draft, (4) risk tier classification, (5) a formed pod with an assigned STO, and (6) appropriate approvals to proceed. Skipping these steps leads to expensive pivots or failed projects.
Opportunity Identification
Sources of AI Opportunities
AI product ideas emerge from multiple sources across the organization:
Business Strategy
Strategic initiatives that require AI capabilities—new markets, competitive response, efficiency mandates
Example: "We need AI-powered fraud detection to enter the payments market"
Operational Pain Points
Process inefficiencies or quality problems that AI might address
Example: "Manual document review is our biggest bottleneck"
Technology Push
New AI capabilities that create previously impossible opportunities
Example: "GPT-4 enables customer service automation we couldn't do before"
Customer Feedback
User requests or behavior patterns suggesting AI value
Example: "Customers keep asking for personalized recommendations"
Opportunity Screening Criteria
Not every idea deserves a pod. Initial screening evaluates:
| Criterion | Questions to Answer | Red Flags |
|---|---|---|
| Business Value | What's the quantified benefit? Who is the sponsor? | Vague benefits, no committed sponsor |
| Problem Clarity | Is the problem well-defined? Do we understand the domain? | "Use AI to improve things" |
| AI Appropriateness | Does this actually need AI? Would rules or simpler methods work? | Deterministic problem dressed as AI |
| Data Availability | Do we have (or can we get) the data needed? | No data, no access, no consent |
| Ethical Feasibility | Can this be done responsibly? What are the risks? | Fundamental ethical concerns |
| Organizational Fit | Do we have the skills? Does this fit our portfolio? | Completely outside our expertise |
Feasibility Assessment
Technical Feasibility
Before committing to a pod, validate that the AI solution is technically achievable:
Data Assessment
Evaluate available data for quantity, quality, relevance, and accessibility. Can you get enough labeled examples? Is there sufficient diversity? What's the data lineage?
Prior Art Review
Has this problem been solved before? What approaches worked or failed? Are there pre-trained models or benchmarks to build on?
Proof of Concept
For novel problems, a quick MVP or prototype may be needed before chartering. Time-box this exploration tightly.
Infrastructure Requirements
What compute, storage, and tooling is needed? Can our platform support this? What's the infrastructure cost?
Ethical & Risk Feasibility
The Ethics Liaison (or ethics function if pod not yet formed) conducts preliminary risk assessment:
- Prohibited Use Check: Does this fall into any prohibited AI categories?
- High-Risk Indicators: Does this affect health, safety, legal rights, employment, or other high-stakes domains?
- Bias Potential: Are there protected groups who could be systematically disadvantaged?
- Privacy Implications: What personal data is involved and under what consent?
- Regulatory Landscape: What laws and regulations apply?
Some opportunities should not proceed regardless of business value:
- Prohibited under EU AI Act or other applicable law
- Fundamental ethical concerns that cannot be mitigated
- Impossible to obtain required data consent
- No technically feasible approach to achieve required fairness
The Charter Process
Model Card as Charter
The Model Card created during "Working Backwards" serves as the formal charter document. Key sections for the chartering stage:
| Section | Chartering State | Approval Significance |
|---|---|---|
| Model Overview | Complete | Defines what we're building |
| Intended Use | Complete | Defines scope and boundaries |
| Success Metrics | Complete | Defines how we'll measure success |
| Training Data | Planned | Confirms data availability |
| Fairness Approach | Planned | Confirms ethical approach |
| Risk Assessment | Complete | Defines risk tier and mitigations |
| Governance | Complete | Confirms applicable requirements |
Risk Tier Classification
Based on the Model Card, assign a risk tier that determines governance requirements:
Tier 1: Low Risk
Internal tools, productivity aids, non-consequential recommendations
Approval: STO + Ethics Liaison
Review frequency: Quarterly
Tier 2: Moderate Risk
Customer-facing features, business process automation, decision support
Approval: AI Council delegate
Review frequency: Monthly
Tier 3: High Risk
Consequential decisions (credit, hiring, health), regulated domains
Approval: Full AI Council
Review frequency: Bi-weekly
Tier 4: Prohibited
Applications that cannot be built responsibly under any governance
Approval: Do not proceed
Review frequency: N/A
Charter Approval Process
STO Submission
The (designated) STO submits the draft Model Card and charter request to the appropriate approval body based on risk tier.
Ethics Review
The Ethics function validates risk tier classification and reviews ethical considerations. May request modifications or escalate tier.
Technical Review
For Tier 2+, a technical review validates feasibility and identifies infrastructure needs.
Approval Decision
Appropriate body approves, requests changes, or rejects. Approval includes resource commitment.
Charter Activation
Approved charter triggers pod formation and resource allocation.
Pod Formation
STO Assignment
If not already designated, the STO is formally assigned at charter approval:
- Selection criteria: Domain expertise, leadership capability, availability
- Commitment: STO commits to Cradle-to-Grave ownership
- Authority: STO receives decision-making authority per risk tier
- Accountability: STO accepts accountability for all pod outcomes
Team Assembly
The STO builds the initial pod team:
Define Roles Needed
Based on the AI product type, determine required roles from the pod archetypes. Identify which roles must be full-time vs. shared.
Recruit or Assign
Work with HR and functional leaders to identify team members. For new pods, prioritize internal candidates with relevant experience.
Assign Ethics Liaison
The Ethics function assigns a Liaison based on the risk tier and domain. High-risk products get dedicated Liaisons; lower-risk may share.
Team Kickoff
STO conducts a formal kickoff with the new pod, reviewing the Model Card, establishing working agreements, and setting initial OKRs.
Kickoff Checklist
Before leaving ideation and entering development:
- Model Card draft complete and approved
- Risk tier assigned with appropriate approvals
- STO formally assigned and committed
- Core pod roles filled or hiring plan approved
- Ethics Liaison assigned
- Budget allocated
- Initial OKRs defined
- Development environment access provisioned
- Data access approved and provisioned
- Stakeholder communication plan established