Tell me what you are trying to build, fix, govern, prove, or launch, and I will point you to the public Folium page that fits. It uses public routes only, so do not send private data here.
AI risk and launch standard
Folium Systems AI Risk Launch Standard
This PDF is meant to be printed only when the paper is worth it. It gives owners, operators, technical reviewers, and leadership a practical launch standard for AI processes that need to become useful without becoming uncontrolled.
- Audience
- Owners, operators, IT, security, staff leaders, executive sponsors
- Purpose
- Define the reviews that make AI work safer, faster, and easier to operate
- Updated
- June 2026
- Use it to decide Whether this is an education, audit, first-build, pilot, trust-review, or operations conversation.
- Keep gated Private data, credentials, customer records, live providers, regulated authority, and production dependency stay outside public review.
- Bring to the room One workflow, one owner, the systems it touches, the records involved, and the decision leadership needs to make.
- The right launch standard protects speed by making risk visible early.
- AI evaluation must test process behavior, source grounding, permissions, and user journeys.
- A review build should not become a dependency until owners, blockers, support, and rollback are clear.
Launch risk system
Risk is not a reason to freeze. It is a system to name, test, and manage.
Folium's launch standard keeps speed and responsibility together by turning blockers, evaluation, support, and monitoring into a visible operating path.
- Govern
- Map
- Measure
- Manage
- Improve
01Frames risk as a managed operating system, not a reason to freeze.
02Connects launch questions to evaluation, support, and improvement records.
03Helps leaders choose the next safe step without losing momentum.
R
Navigation map
Choose the review route before reading cover to cover.
This packet is meant to support a real decision meeting. Let each reviewer enter through the route that matches their job, then bring the group back to the same controlled next step.
- Decision route
- Operating route
- Trust route
Executive route
Decision first
Start with the cover, visual summary, executive read, controls, first ninety days, and handoff. This route helps leaders decide whether the next move is education, audit, first build, pilot, or operations.
- Outcome
- Risk
- Owner
- Next gate
Operations route
How the work will run
Read the workflow map, procedures, operating roles, metrics, first sprint, and buyer worksheet. This route shows whether staff can actually use, review, and improve the future process.
- Workflow
- Staff
- Support
- Improve
Technical and trust route
Where the boundaries live
Focus on records and work products, controls, risk assumptions, reference work products, trusted knowledge, runtime placement, and launch conditions before any private access expands.
- Source
- Access
- Runtime
- Rollback
Buyer session route
Turn reading into a working session
Use the discovery questions, role review route, buyer worksheet, and engagement fit ladder to prepare one process, one owner, one source map, and one next decision.
- Process
- Examples
- Questions
- Decision
Best use: read the route that matches your role, mark the questions that still need proof, and leave with one narrow decision instead of a vague AI wishlist.
01
Launch thesis
Fast AI work needs better stop signs, not slower ambition.
The Folium Systems AI Risk and Launch Standard is built for businesses that want to move quickly without letting AI become a mystery dependency. The standard names the control points that protect speed: govern, map, measure, manage, monitor.
- Record
- Boundary
- Action
Govern
Name authority before use
Owners, permissions, review points, live-action limits, escalation, blocked actions, and decision rights.
Map
Draw the process before automating
Systems, users, data sources, provider handoffs, runtime placement, failure modes, and dependencies.
Measure
Test behavior, not only presentation
Evaluate retrieval, answer quality, tool routing, browser paths, refusals, latency, accessibility, and known limits.
Manage
Operate after launch
Support, incidents, rollback, release notes, training, source freshness, monitoring, and improvement loops.
02
Risk register
The risks that matter most are operational.
Most AI risk discussions focus only on model behavior. Folium expands the view to the full service map around the model.
- Decision grid
- Review lens
- Next step
| Risk | How it appears | Launch control |
|---|---|---|
| Wrong answer | AI gives inaccurate or stale information with confidence. | Source-grounding checks, eval cases, refusal rules, review path. |
| Wrong action | AI updates, sends, routes, or triggers something it should not. | Permission table, human review, blocked actions, audit trail. |
| Wrong data | Private, regulated, or secret data enters prompts, logs, or external tools. | Data boundary map, redaction, retention rules, secrets custody. |
| Wrong runtime | Sensitive work is placed in a runtime that does not fit privacy, latency, cost, or control needs. | Runtime placement decision, fallback, portability, vendor-exit plan. |
| Wrong owner | No one owns quality, support, rollback, source freshness, or staff adoption. | Owner map, support model, incident route, training guide. |
| Wrong launch | A review build becomes a production dependency without records. | Launch blockers, go/no-go review, known-limits record, pilot criteria. |
03
Launch readiness
A process should earn each next level of authority.
Folium uses launch readiness reviews to decide when a process is safe to inspect, safe to sandbox, safe to pilot, or ready for production planning.
- Decision grid
- Review lens
- Next step
| Review stage | Minimum record | Decision |
|---|---|---|
| Stage 1: Public review | Public-facing page, PDF, screenshot, or process sketch. | Continue only if the value is clear enough to scope. |
| Stage 2: Scoped process | Business process, users, systems, data classes, owners, and exclusions. | Continue only if the first review build is narrow and safe. |
| Stage 3: Sandbox behavior | Clickable flow, redacted sources, eval cases, known limits, staff review. | Continue only if behavior is useful and inspectable. |
| Stage 4: Architecture review | Runtime map, permissions, logs, secrets, support, fallback, rollback. | Continue only if reviewers can approve pilot conditions. |
| Stage 5: Controlled pilot | Limited users, monitored use, training, incident path, repair cadence. | Continue only if records support expanded dependency. |
| Stage 6: AI operations | Ongoing monitoring, cost control, source maintenance, change review, adoption metrics. | Operate only with clear ownership and improvement rhythm. |
04
Evaluation discipline
Evaluation should test the job the process is supposed to do.
A useful AI launch standard measures whether the system helps the business perform the task safely, not whether a single answer sounds polished.
- Record
- Boundary
- Action
Behavior cases
Realistic prompts, messy user language, edge cases, bad inputs, missing data, and role-specific questions.
- Happy path
- Messy path
- Boundary path
- Refusal path
Source and retrieval checks
Verify that answers come from approved sources, stale sources are flagged, and unsupported claims are avoided.
- Approved sources
- Freshness
- Citation need
- Unsupported claim handling
Tool and route checks
Confirm that AI chooses the right tool, refuses blocked tools, escalates sensitive actions, and does not invent authority.
- Allowed tool
- Blocked tool
- Human review
- Escalation
User journey validation
Check the actual user path in browsers and devices, including mobile, tablet, desktop, forms, downloads, and visible states.
- Desktop
- Tablet
- Mobile
- Download and print
05
Launch blockers
These failures should stop the launch.
Blockers are not paperwork. They protect the customer from turning a promising validation into a brittle dependency.
- Checklist
- Owner path
- Release signal
- The AI claims it can perform live actions that are not approved.
- Private data, secret labels, internal source names, or credentials leak into public output.
- The system cannot explain what source supports a factual answer.
- No owner exists for source freshness, support, rollback, incident response, or launch signoff.
- Staff cannot explain what the AI is allowed to do and when to escalate.
- The process affects money, customers, access, compliance, or reputation without a human review point.
- The buyer cannot see known limits, failed cases, repair decisions, or acceptance criteria.
- The launch path has no degraded mode if a model, retrieval source, API, database, or provider fails.
06
Human adoption
AI launch risk includes people.
A workflow that is technically impressive can still fail if staff do not understand it, trust it, correct it, or know when to override it.
- Record
- Boundary
- Action
Role clarity
Staff should know which part of the job AI supports and which part remains human responsibility.
Training packet
Users need simple examples, limits, escalation steps, and what-good-looks-like guidance.
Feedback loop
Staff need a way to report wrong answers, missing sources, confusing routes, and adoption friction.
Manager visibility
Leaders need operational signals: usage, quality, savings, errors, support load, and readiness to expand.
Job strengthening
Folium frames AI as capacity expansion: reduce repetitive work, preserve human judgment, and strengthen staff capability.
Fear reduction
People fear what they cannot see. The launch standard makes the workflow, limits, and support path visible.
07
Operating cadence
After launch, the system still needs care.
AI work changes after release: sources age, staff learn, costs move, edge cases appear, tools update, and customers ask new questions. The standard defines how the system stays healthy.
- Decision grid
- Review lens
- Next step
| Cadence | Review focus | Output |
|---|---|---|
| Weekly early pilot | Usage, friction, wrong answers, failed routes, support tickets, staff comments. | Repair list, training note, source update, or go/no-go decision. |
| Monthly operations | Quality trend, cost trend, source freshness, incidents, adoption, role changes. | Improvement backlog and release note. |
| Quarterly executive review | Business value, risk posture, expansion candidates, vendor/runtime fit, staffing impact. | Continue, expand, refactor, retire, or redesign decision. |
| Incident-triggered | Unsafe output, wrong action, data issue, provider failure, user harm, regulatory concern. | Rollback, communication, repair, root cause, and relaunch review. |
08
Risk appendix
The expanded library should make launch risk more concrete.
The new PDFs add more domain-specific launch gates. Forward engineering, commerce, staff adoption, local AI, and audits all need their own stop/refine/launch signals.
- Checklist
- Owner path
- Release signal
- Stop if source truth is not known.
- Stop if staff cannot explain what the AI is allowed to do.
- Stop if runtime placement is selected before data sensitivity is known.
- Stop if commerce AI can invent pricing, availability, policy, warranty, or claims.
- Stop if an agent can use tools without visible authority.
- Stop if no owner can support the system after launch.
09
Reader route
Use the packet by role, not only from front to back.
The strongest review happens when each stakeholder reads the pages that match their decision rights. This route helps a buyer turn the packet into a working session instead of a passive download.
- Decision grid
- Review lens
- Next step
| Reviewer | What to inspect | Question to answer |
|---|---|---|
| Owner or CEO | Value, risk, first process, launch gates, and next-stage decision. | Is this a controlled way to move from AI pressure to capability? |
| Operations lead | Workflow steps, people affected, support path, and improvement rhythm. | Can the team operate this without creating a new hidden burden? |
| Technical lead | Systems, runtime, integrations, logs, fallback, and data boundaries. | Can the architecture be supported and secured? |
| Security or procurement | Access, retention, provider exposure, blocked data, permissions, and rollback. | What must be true before private access expands? |
| Staff manager | Training, role clarity, human review, correction path, and adoption risk. | Will this strengthen the people doing the work? |
| Investor or partner | Category, repeatability, public boundary, and diligence path. | What deeper records should be requested before believing the thesis? |
10
Working-session worksheet
Bring these answers into the next Folium conversation.
A printable PDF should help the buyer prepare. These prompts keep the conversation attached to real work, real systems, real people, and an honest boundary between public review and private implementation.
- Checklist
- Owner path
- Release signal
- Name the one workflow that hurts most today and the person who owns it.
- List every system, file, inbox, store, database, spreadsheet, vendor, or manual handoff the workflow touches.
- Separate data into public, internal, customer, regulated, confidential, credential, and blocked classes.
- Identify which steps are slow, duplicated, risky, customer-visible, staff-heavy, or expensive.
- Write down what AI may draft, retrieve, recommend, route, block, or escalate.
- Write down what AI must not execute without human approval.
- Bring examples of good output, bad output, common exceptions, missing data, and escalation moments.
- Decide what record would justify the next step: audit, first build, architecture review, pilot, or operations.
11
Decision matrix
The next step should be earned by the record.
Folium's public packets are built to create a practical decision, not only a favorable impression. Use this matrix to choose the next move after review.
- Decision grid
- Review lens
- Next step
| Decision | Use when | Expected next record |
|---|---|---|
| Stop | The process has no owner, no clear value, or unsafe data pressure. | Stop note and conditions that would need to change. |
| Refine | The pain is real but the workflow, source truth, or approval path is unclear. | Revised process map and missing-information list. |
| Audit | The buyer sees the need but does not know which AI lane should come first. | AI systems audit, inventory, scorecard, and first-lane recommendation. |
| First build | One safe process, owner, source boundary, and desired output are clear. | Working surface, known limits, browser checks, and next-stage blockers. |
| Architecture review | A useful build exists but private access, runtime, support, or authority needs review. | Data boundary, runtime matrix, permission map, and rollback path. |
| Operate | A pilot has value, owners, support, monitoring, and improvement rhythm. | AI operations cadence, source refresh plan, release notes, and issue loop. |
12
Plain-language glossary
The buyer should not need to speak engineer to read the packet.
Folium uses technical terms when needed, but a public packet should translate them into operating language. The goal is to help the buyer understand the decision, not admire the vocabulary.
- Decision grid
- Review lens
- Next step
| Term | Plain meaning | Why it matters |
|---|---|---|
| RAG | AI answers from approved company material instead of memory alone. | It keeps answers tied to business sources. |
| Agent | A guided AI worker that can follow a task path with tools and limits. | It needs permission, logging, and human review. |
| Runtime | Where the AI work runs: cloud, private endpoint, local machine, or hybrid path. | It affects privacy, cost, speed, control, and support. |
| Evaluation | A test set that checks whether the system behaves correctly on real tasks. | It exposes failures before the business depends on the system. |
| Governance | The rules for data, access, authority, logs, review, rollback, and ownership. | It keeps AI useful without giving it unmanaged power. |
| Launch room | The operating board for owners, support, blockers, training, incidents, and next releases. | It turns a build into a system the business can run. |
13
Next step
Launch discipline is how Folium moves fast without pretending risk disappeared.
Use this standard to decide whether one AI process is ready for scoped review, a sandbox, a pilot, or a production plan. The answer should come from records, not excitement.
Bring the process
Name the business process, the systems involved, the people affected, and the decision this PDF should support.
Separate review from production
Keep public examples, sandbox review, pilot access, and production dependency in separate stages with clear owners.
Ask for the record
Request screenshots, browser checks, known limits, launch blockers, support plans, and the next approval path.
Common questions
Questions this page answers.
Does AI diligence require private data?
Not at first. A buyer can begin with public materials, redacted examples, approved records, architecture summaries, and workflow interviews before sensitive access is considered.
What should AI due diligence verify?
It should verify workflow fit, data handling, security posture, model or tool routes, evaluation quality, support ownership, monitoring, rollback, known limits, and launch gates.
Can Folium support investor or partner diligence?
Yes. Folium can help organize buyer-safe diligence records and explain AI capability, boundaries, dependencies, and open conditions in plain language.