Riseplan from Roast & Rise
Open Source and Local AI Models for Work
Model evaluation and pilot deployment decision process: from model landscape scan, use-case matching, license/security review, through pilot execution and go/stop/scale decision.
Learners will confidently distinguish between open, source-available, and local models; select where open/local models create business advantage; avoid common blind spots; and guide a 30-day real-world pilot with best-practice governance.
Course thesis
Most companies misunderstand what 'open' means in AI, underestimate the trade-offs, and miss the chance to build custom, resilient, and governed model portfolios. In 30 days, you'll learn to decode open/local AI, map models to real needs, and launch a pilot that proves value, safety, and control.
What you leave with
Learners will confidently distinguish between open, source-available, and local models; select where open/local models create business advantage; avoid common blind spots; and guide a 30-day real-world pilot with best-practice governance.
Learner
Founders, managers, operators, IT/security leads, and AI owners responsible for guiding company decisions on adoption and use of open-source or local AI models.
Workflow
Model evaluation and pilot deployment decision process: from model landscape scan, use-case matching, license/security review, through pilot execution and go/stop/scale decision.
Behavior
Learners will confidently distinguish between open, source-available, and local models; select where open/local models create business advantage; avoid common blind spots; and guide a 30-day real-world pilot with best-practice governance.
Outcomes
What the learner should be able to do after finishing this public Riseplan.
Explain key terms in plain English: open-source AI, open weights, source-available, local inference, quantization, fine-tuning, RAG.
Map the key open/local models, licenses, strengths, and limitations for your context.
Build a use-case fit matrix to match business needs to model options.
Design a 30-day pilot for a high-value use case: select model, perform governance checks, define checks and success rules.
Deliver and measure the pilot: make a clear go/stop/scale recommendation, with an auditable record.
Chapters
01
Land on Solid Terms: Decoding 'Open' and 'Local'
Build the real glossary that cuts through open-source AI confusion - so your team debates facts, not feelings.
Why this matters in the workflow
If your team can't name what 'open-source' or 'local AI' really means, every conversation is noise. Buying, deploying, securing, or even talking about AI stays locked behind half-truths and vendor spin. A glossary, reviewed and shared, ends the guessing - no more accidental compliance breaches, stalled pilots, or technical dead-ends caused by foggy language.
The working model
- Open-source AI: Meets the OSI (Open Source Initiative) AI Definition 1.0 - grants freedom to use, study, modify, share. This includes code, model weights, AND crucial data or training details. [Source](https://opensource.org/ai/open-source-ai-definition).
- Most so-called open models are only 'open weights' or 'source-available': you can download the model, but not the full recipe or training data/history. Always check the license.
- Local inference: Running the model (making predictions or generating output) on your own hardware - can be laptops, servers, edge devices, or private cloud. No outside API call needed.
- Source-available: You can see and maybe use the code or model, but it isn't open-source - you may have use restrictions, missing data, or unclear modification rights.
- Private cloud: Your company's managed cloud servers, not vendor-hosted. Useful for privacy/data sovereignty.
- Quantization: Compressing a model to use fewer bits and memory - makes local/edge deployment possible.
- Fine-tuning: Adapting a pre-trained model using your own data - usually needs source access, not just weights.
- Retrieval Augmented Generation (RAG): Adding fresh company data to a model's outputs without retraining by letting it look up (retrieve) and use new data in real time.
- Licensing: The legal terms controlling how a model, its data, or its code can be used. Examples: Apache 2.0 (very open), MIT (permissive), custom/closed (often restrictive).
Quality checklist
Each term uses plain English, not tech jargon.
Every definition is matched with a business-relevant anchor.
Includes at least one skeptical question per term.
Peer-reviewed by both a technical and non-technical stakeholder.
Captured clarifications or challenges are integrated into the glossary.
Common mistakes
Copy-pasting definitions from Wikipedia or documentation - too dense for business use.
Skipping the practical impact - leaving terms abstract.
Not testing the glossary with actual peers - risking misunderstood or unused terms.
Overlooking licenses - assuming 'open' means fully open-source.
Ignoring terms that come up in live AI/vendor discussions (like 'quantization', 'inference').
Checkpoint
Can you confidently define and explain the difference between 'open weights', 'source-available', and true open-source AI to a skeptical manager?
Exercise
Draft Your Company-Ready Open & Local AI Glossary
Steps:
- Download or copy the template below.
- Add concrete definitions for at least eight key terms from this chapter (see examples - but use language your stakeholders will get).
- For each term, add:
a) A practical sentence showing how it matters to real work. b) One question a skeptical stakeholder might ask about the term.
- Share your draft with one person in tech, one in business/non-tech roles. Ask for confusion points or challenge cases. Capture any needed clarifications.
- Finalize: edit with their notes, then save the glossary in your workspace/doc center - mark as ready for review.
Time check: You can complete a first version in 15 minutes. Use plain English, not Wikipedia.
Use this at work tomorrow
Bring your glossary draft to your next model meeting and kill the confusion before it spreads.
02
Map the Model Landscape: Who's Actually Open, Local, or Both?
Cut through vendor hype and map open/local AI models with proven facts. Spot what is truly open, what can run locally, and which fits your use case - before you commit.
Why this matters in the workflow
Wild claims and lingo confusion cloud every AI sourcing conversation. One slip - confusing a closed API for an open model, or assuming source-available is true open-source - costs money, exposes you to security and legal risks, or boxes you into a dead end. Before you pilot or buy, you need facts. A clear model/source map demystifies the landscape for any founder, IT lead, or operator tasked with selecting the right AI engine.
The working model
A practical model/source map lists key open and local AI models, spells out what each one actually offers, and tags the specs and legal status that shape deployment. This isn't a spreadsheet of marketing claims - this is due diligence on paper, ready for a decision call.
Quality checklist
Each row is filled using a public, official source (not blog summaries or vendor decks).
All critical columns completed: license, openness, deployment, blockers.
Gaps/unknowns are flagged clearly - no empty cells or unmarked TBD.
Blockers are specific (e.g., 'MIT license, requires legal review' or 'GPU required').
Output is shared and discussed with at least one stakeholder (IT/security/legal/owner).
Common mistakes
Taking 'open weights' as full open-source; skipping license details.
Filling columns based on memory or marketing slides, not actual repo/doc.
Leaving unknowns unflagged - these bite later in procurement or deployment.
Failing to compare local vs. cloud deployment (some models are not actually local-capable).
Not updating the map when a model changes license or adds features.
Checkpoint
Can you fill in a full row for any model, using a real public source and tagging unknowns/blockers honestly? Share with a stakeholder - if you get pushback or questions, review your data. Ready for use-case fit mapping.
Exercise
Build a Real Model/Source Map for Your Next Workflow
Draft the first three rows of your own model/source map. You have 15 minutes. Use official sources for each model, fill every column, and flag gaps for team review. Bring this draft to your next model selection meeting.
Steps:
- Pick 2 - 3 candidate models relevant to your next workflow or pilot (e.g. Mistral, Gemma, DeepSeek, IBM Granite, Qwen).
- For each, open the official repo or announcement. Find:
- License type (Apache 2.0, MIT, source-available, etc)
- What's actually open (weights, code, data?)
- Deployment options (Ollama, llama.cpp, local/cloud, etc.)
- Key features and use-case flags.
- Known blockers - note any license/data/geopolitical risks.
- Fill in the template below. If you're missing facts, highlight with a "?" and note that in the blockers column.
- Save and share your output with your team.
Use this at work tomorrow
Build your own model/source map before any new AI project - run a quick licensing and deployment check, and bring the facts to your next selection call.
03
Where Do Open and Local Models Actually Matter?
Learn how to map your business priorities (privacy, latency, cost, sovereignty) to a concrete decision on when to choose open-source, local, closed, or hybrid AI models. Build a use-case fit matrix and use it to land a defensible model choice for a real workflow.
Why this matters in the workflow
Open and local AI models offer privacy, resilience, and control you will not get from a standard cloud API. But unless you match model choices to the true pinch points of your workflow, you risk complexity, overhead, or - worse - security theater. The right model deployment means the difference between value and noise, between locked-in and strategic control.
This workflow - model fit must be intentional. Too many teams chase "open" models for prestige, or fall into closed clouds out of inertia. Use a fit matrix to put reality - needs, constraints, trade-offs - on the table for every decision.
The working model
Quality checklist
Every business requirement is listed in clear, plain English.
At least three model/deployment options are mapped in the matrix.
Each cell has a concrete note - no empty or generic ratings.
Clear rationale for the final deployment choice is documented.
At least one key assumption is surfaced for validation, not swept under the rug.
Common mistakes
Leaving requirements vague or copying them from an AI vendor website.
Failing to check model license or data residency/nationality constraints.
Ignoring integration or latency limitations - assuming 'local' is always fast or 'open' is always free.
Letting hype or bias pick the winner before matrix is filled out.
Not clearly recording trade-offs for stakeholders.
Checkpoint
Did you draft a use-case fit matrix with business requirements, rate at least three deployment options, and write a clear rationale and validation assumption?
Exercise
Build Your Use-Case Fit Matrix (Live Workflow)
Steps
- Pick a real use case where you suspect open/local models could create business value or reduce risk. E.g., document search, customer support, internal code generation, contract analysis.
- List the must-have requirements for this use case: privacy, latency, explainability, customization, cost, data residency, regulatory needs, etc.
- Fill out the Use-Case Fit Matrix template below for at least three deployment options (closed API, source-available/open-weight, open-source OSI, local, hybrid).
- For each criterion, rate (Good, Fair, Poor) and make a one-line note - especially where there is a gap, risk, or deal-breaker.
- Write a short rationale for the best-fit model/deployment class and state one assumption that must be validated before moving to build/pilot.
Within 15 minutes, you'll have a concrete fit matrix and a defensible model/deployment recommendation to discuss with stakeholders.
Use this at work tomorrow
Run the fit matrix on a single critical workflow before your next AI vendor call. Show the decision logic to a stakeholder: it will smoke out hidden risks or clear wins faster than any 'AI 101' slide.
04
Pilot with Precision: Design and Govern Your 30-Day Test
Learn how to design a focused, low-risk 30-day pilot of an open or local AI model: clarify goals, capture risks, secure governance, and produce the evaluation/rollback playbook decision-makers require.
Why this matters in the workflow A model pilot is not a vanity demo. If you skip structure - clear purpose, baseline, owner, license, and governance - you risk data leaks, wasted effort, or a pilot that teaches nothing. The right 30-day pilot turns a black box into evidence. It builds trust and earns leadership's go/no-go with real-world results, not vendor slides.
The working model Every successful open/local AI pilot stands on three working doc sets:
- Pilot Charter: why this workflow, what value, who owns it, what baseline you're aiming to move, what the outcome must prove.
- Evaluation Scorecard: hard metrics and soft signals, tracked week by week.
- Governance Checklist: permissions, security, data residency, rollback - review this before day one, not after a red alert.
A good pilot is not wide. It's sharp, fast, and controlled. You need to answer: "Did this model, run as specified, make this workflow smarter, safer, or cheaper - without new risk?"
How to apply it
- Pick the pilot use-case. Use your fit matrix output. Go focused: one clear workflow (e.g., customer service reply draft, IT ticket triage, summarizing an RFP, extracting data).
- Shortlist models. Confirm license, openness, local/cloud, and deployment restrictions. Document any doubts (e.g., Mistral Small 4: check Apache 2.0 license details; Gemma: confirm that weights + code meet all internal policy).
- Draft a pilot charter. Name the workflow, model setup, owner, goal, team, business value, baseline metric, and the success/failure bar for go/scale.
- Define the evaluation scorecard. List objective success indicators (accuracy, latency, cost, error rate, user NPS, time saved) and subjective ones (stakeholder feedback, usability).
- Build the governance checklist. Assess privacy, access/logs, rollback plan, security controls, and who signs off. No model touches live data until this is done.
- Run the pilot. Track metrics every week. Document issues. Hold a mid-point review: still aligned, or time to adjust?
Quality checklist
Charter names a specific workflow, pilot owner, and business outcome.
Baseline and goal are measurable and relevant.
Evaluation metrics (3+) are meaningful, tracked, and drive the pilot decision.
Licensing/openness checks documented for chosen model(s).
Governance checklist includes privacy, rollback, signoff, and security - no gaps.
Ready to share with technical and business decision-makers.
Common mistakes
Pilot aim is too vague - no clear workflow.
No documented baseline, so no way to measure improvement or risk.
Skipped license or security review - leads to last-minute delays or retraction.
Scorecard lacks concrete metrics or isn't actually used.
No named pilot owner - no one drives the process.
Missing rollback plan - pilot can't safely stop if issues found.
Checkpoint
Can you show a completed pilot charter, scorecard, and governance checklist for a live workflow, with model license/security flagged?
Exercise
Draft Your Pilot Charter, Scorecard, and Governance Checklist
Your task:
Pick a real, high-leverage workflow in your company. Using the template, draft:
- A short pilot charter
- An evaluation scorecard: 3 - 5 metrics
- A governance checklist
Steps:
- Define the workflow and why it matters.
- Pick the model(s) you'll pilot. Check license and openness (use public sources - note what you still need to verify).
- Complete the pilot charter, scorecard, and governance checklist below.
- Share with a technical and a business stakeholder for review: "Is this clear, safe, and enough to run a real 30-day pilot?"
Use this at work tomorrow
Pick your highest-value workflow and write a 1-page pilot charter and governance checklist before you touch a single model.
05
Decide and Scale: Learn, Measure, Go or Roll Back
Move beyond pilot hype. Measure real results. Deliver a clear go/stop/scale call, supported by evidence, ready for audit and action.
Why this matters in the workflow
Running a pilot with open or local AI means nothing unless you land the answer: do we scale, roll back, or stop? Every technical, legal, and business team will want receipts. Measurement, documentation, and a single decision - auditable. This closes the loop. Your pilot wasn't just a test. It's now a company decision backed by evidence, not a tech demo or a leap of faith.
The working model
- Inputs: Pilot charter, evaluation scorecard, governance checklist, baseline data, and performance during the pilot window
- Actions: Collect post-pilot data; fill a summary report; run a post-mortem on process, not just tech; state the go/stop/scale call with proof
- Outputs: Evidence-backed summary, decision memo, documented learnings, next steps
The decision isn't just technical - risk, compliance, capacity, and business value all count. Auditability matters: show your work, defend your decision, learn for next time.
Quality checklist
Decision is clear: go, stop, or scale - not fuzzy.
Metrics are recorded and compared to baseline.
Learnings address both technical/business findings.
Risks and surprises aren't hidden or glossed over.
Memo is written for audit and stakeholder trust.
Next steps are actionable and assigned.
Common mistakes
Vague or hedged recommendation - unclear whether to proceed.
Only listing technical results - misses business impact or risk.
No stakeholder distribution - buried in a private folder.
Skipping post-mortem - no process learning secured.
Checkpoint
Can you present a clear, evidence-backed go/stop/scale decision for your pilot that a skeptic could audit and follow up on?
Exercise
Draft Your Pilot Post-Mortem and Go/Stop/Scale Memo
Your task:
Take your (real or hypothetical) open/local AI pilot and fill in a decision memo. This will:
- Document pilot metrics vs. baseline
- Note key learnings (value, surprise, risks)
- State a clear go/stop/scale recommendation
- List immediate next steps and changes for governance/process
- Package it as a summary you can present or file for later audit
Steps:
- Review your pilot documentation (charter, baseline, scorecard, stakeholder notes).
- Fill in the provided memo template (below).
- If this is a real pilot, circulate to one stakeholder for feedback. If not, role-play the review solo.
You have 15 minutes. Make your call and write it down.
Use this at work tomorrow
After your next AI pilot, fill in the post-mortem memo and share your decision broadly. Build trust with receipts.
30-day path
Week 1: Build common language - share your draft glossary and model/source map with stakeholders.
Week 2: Run a use-case fit workshop - test candidate models/architectures for your high-value workflow.
Week 3: Launch pilot - finalize pilot charter, run model locally/in private cloud, track evaluation and baseline data.
Week 4: Review - measure results vs. baseline, complete post-mortem, make a documented go/stop/scale recommendation.
Success signals
Peer-clarified glossary: non-specialist team leads can explain and use terms correctly.
Model/source map referenced in model sourcing or AI procurement discussion.
Use-case fit matrix used in a real use-case selection or architecture workshop.
Pilot runs with governance, license/security review, baseline, and rollback in place.
Clear go/stop/scale recommendation, with supporting output, shared and understood by all decision makers.
Reflection prompts
Where does this topic show up in real work?
What behavior should change first?
What evidence would prove this RisePlan worked?
Manager checklist
Choose one owner for the behavior change.
Use the exercise on live work.
Review the output before scaling the habit.
Decide what changes after 30 days.
Want this shaped around your company?
Risey can research your company foundation first, then build a version of this path around your real workflows, customers, and culture.
Start with your company