Implementing AI Studio & AI Assistant: A Provider Configuration Manual

Who this manual is for

This manual is for the administrator responsible for turning on AI features inside SAVHN — AI Studio and AI Assistant specifically. It covers configuring an AI provider, understanding how SAVHN handles AI features that don't yet have a connected model, and rolling access out to teams in a way that builds trust rather than confusion.

The most important thing to understand before you start: SAVHN does not fake AI functionality. Every AI feature in the platform is either backed by a real, connected model provider, or it is plainly labeled as a placeholder that hasn't been configured yet. Nothing in between. This manual assumes you want to move features from the second category into the first, deliberately and in the right order.

Prerequisites

• Organization and role-based permissions already set up, since AI Studio and AI Assistant access should be scoped by role like any other module.
• A decision on which AI provider(s) your organization intends to use, along with the API credentials needed to connect them. SAVHN connects to your provider's credentials — it does not supply a hidden default model on your behalf.
• Awareness of which modules and workflows you intend AI features to touch first (drafting responses in Tickets, summarizing records in CRM, and so on), so provider configuration isn't done in a vacuum.
• A named internal owner for AI configuration going forward — provider credentials, usage limits, and rollout scope are ongoing responsibilities, not one-time setup.

Step 1: Understand the honesty pattern before configuring anything

SAVHN's AI features follow a consistent rule: a feature either has a real, connected model behind it, or it is visibly and plainly labeled as not yet configured. There is no feature in the platform that pretends to run on AI while silently returning canned or fabricated output. If you open AI Studio and see a feature marked as a placeholder, that label is accurate — it means no provider is connected to it yet, not that the feature is broken or hidden.

This matters for how you plan rollout: your team will encounter both real, working AI features and plainly-labeled unconfigured ones as you work through setup, and both states are intentional and honest, not bugs. Do not attempt to make an unconfigured feature "look" active before it has a real provider connected — the point of the labeling is that your team can trust what they see.

Step 2: Choose and configure your AI provider

In AI Studio, navigate to provider configuration and connect the AI provider your organization has chosen, using your own API credentials. This is where the "real model" side of the honesty pattern gets activated — once a provider is connected, features that depend on it switch from placeholder state to live.

If your organization plans to use more than one provider for different purposes (for example, one provider for a specific specialized workflow and another as your general default), configure each deliberately rather than leaving a default in place you haven't actually reviewed. Confirm the credentials are valid and the connection is live before moving to the next step — a misconfigured or expired credential will surface as an unconfigured/placeholder state again, which is the correct, honest behavior, but worth understanding so you don't mistake it for a system bug.

Step 3: Decide which AI features to activate first

Not every AI-touched workflow needs to go live simultaneously. Look at your module footprint and decide where AI assistance would genuinely help first — common starting points are AI Assistant support for drafting or summarizing within a module your team already uses heavily, such as CRM or Tickets. Activating a narrow, well-understood set of features first makes it much easier to evaluate whether the output is actually useful before expanding scope.

Step 4: Configure AI Assistant's scope and access

AI Assistant, like every other module, should be scoped through role-based permissions rather than opened to the entire organization by default. Decide which roles get access to AI Assistant, and within that, which modules or record types it can act on. A Support Agent role might reasonably get AI Assistant help drafting ticket responses; that doesn't automatically mean the same access should extend to drafting content inside Payroll or Finance records.

Step 5: Pilot with a small group and review real output

Before rolling AI Assistant or AI Studio-configured features out broadly, pilot with a small group doing real work. Have them evaluate the AI output the same way they'd evaluate a new hire's early work — useful as a draft or accelerant, but reviewed before it's treated as final. This is standard practice for any AI-assisted workflow and isn't specific to SAVHN, but it matters more here because your team needs a working sense of when a feature is genuinely AI-backed versus when they might be looking at something not yet configured.

Step 6: Set expectations with the team about labeling

Before wider rollout, brief your team explicitly on the honesty pattern from Step 1: if they see a feature labeled as a placeholder, that's accurate information, not a defect to report. This avoids a wave of "is this broken?" questions once more people start exploring AI Studio and encounter both live and unconfigured features side by side.

Step 7: Expand rollout and review usage periodically

Once the pilot group confirms the configured features are working as expected, expand access according to your role plan. Set a periodic review (monthly or quarterly, depending on how actively your organization uses AI features) to check provider credentials are still valid, usage is within expectations, and any newly enabled modules have had their AI-touched features deliberately reviewed rather than left in whatever default state they arrived in.

Why the honesty pattern is worth protecting

It's worth pausing on why the placeholder-labeling approach matters beyond just being accurate. The moment a team member can't trust that an "AI-powered" label actually reflects a working, connected model, they stop trusting AI features generally — including the ones that are genuinely live and useful. A single instance of a feature quietly faking output, even accidentally through a misconfiguration nobody caught, does more damage to adoption than a dozen honestly-labeled placeholders ever would.

This is also why Step 2's verification matters more than it might seem: a provider connection that looks configured but isn't actually live (an expired credential, a typo in an API key) should surface as a placeholder state, not as a broken feature that appears to work but silently doesn't. If you ever see a feature behaving inconsistently — sometimes producing real output, sometimes not — treat that as a provider configuration issue to investigate immediately, not something to work around.

Connecting AI features to the modules they touch

AI Studio and AI Assistant don't operate in isolation — their usefulness depends entirely on the modules they're configured to act within. Before activating an AI feature tied to a specific module (drafting ticket responses, summarizing CRM activity, surfacing patterns for Manager Copilot), confirm that module itself is already in stable, real use by your team, following the sequencing guidance in the Module Marketplace implementation manual. An AI feature configured against a module with sparse or inconsistent data will produce correspondingly sparse or unhelpful output — not because the AI feature is broken, but because there's little real substance for it to work with yet. Sequence AI feature rollout to follow module maturity, not to race ahead of it.

Handling questions from a skeptical team

Some members of your team will be enthusiastic about AI features from day one; others will be reasonably skeptical, either about AI generally or specifically about whether output from a connected model can be trusted for real work. Both reactions are worth taking seriously rather than dismissing. For the skeptics in particular, the honesty pattern from Step 1 is your strongest argument — you can show them, concretely, that a feature is either backed by a real provider connection they can verify, or plainly marked as not yet active. That's a fundamentally different conversation than asking someone to trust a system that claims AI capability without any way to verify what's actually happening behind it.

Encourage early users to treat AI Assistant output the way they'd treat a capable but new colleague's first drafts: useful as a starting point, reviewed before being treated as final, and something that gets more trusted over time as its track record on real work builds up. This framing tends to land better than presenting AI features as either infallible or as a gimmick — it's neither, and setting that expectation early avoids both over-reliance and premature dismissal.

Rollout checklist at a glance

Rollout stage	What "done" looks like
Provider configured	Credentials connected and verified live in AI Studio
Feature selection	A specific, named set of AI features activated for pilot
Access scoped	AI Assistant access assigned by role, not organization-wide default
Pilot reviewed	Real output evaluated by real users before wider rollout
Team briefed	Everyone understands placeholder labeling is honest, not broken
Ongoing review	A recurring check on credentials, usage, and newly enabled features

Common Pitfalls

Assuming every AI-labeled feature is already active. Some are placeholders until a provider is configured. Check AI Studio's actual state rather than assuming based on a feature's name or description.

Connecting a provider and enabling every AI feature at once. Just like module rollout generally, a narrow, deliberate first set of AI features is easier to evaluate honestly than a broad simultaneous activation.

Not scoping AI Assistant access by role. AI Assistant should follow the same role-based permission discipline as every other module — organization-wide default access to an AI assistant that can act across modules is a bigger exposure than it looks.

Treating AI output as final without review, especially early in rollout. The pilot phase exists specifically to build a real sense of output quality before your team relies on it unsupervised.

Not briefing the team on placeholder labeling before wider rollout. Without context, an honestly-labeled unconfigured feature reads as a bug report waiting to happen.

Frequently Asked Questions

What does it mean if an AI feature in AI Studio shows a "not configured" or placeholder label?

It means no AI provider is currently connected to that specific feature, and the platform is telling you that plainly rather than faking output. This is intentional behavior, not an error — configure a provider for that feature if you want it live.

Can we use different AI providers for different features?

Yes. Provider configuration in AI Studio is not a single global switch — you can connect different providers to different features depending on your organization's needs, as long as each connection is deliberately configured rather than left to a default.

Does AI Assistant access need separate permission configuration from other modules?

Yes, treat it exactly like any other module in your role-based permission model. Decide which roles get access to AI Assistant and what it's allowed to act on, rather than leaving it open by default to everyone with a login.

What happens if our AI provider credentials expire or become invalid?

Features that depended on that provider return to the plainly-labeled placeholder state described in Step 1, rather than silently failing or returning fabricated output. This is the same honesty pattern working as intended — it tells your team the connection needs attention rather than hiding the problem.

Getting started

AI Studio and AI Assistant are only as useful as the provider configuration and rollout discipline behind them — a real, connected model doing a narrow job well beats a broadly enabled but unreviewed one every time. SAVHN's 7-day free trial gives you enough room to connect a provider and pilot a first set of AI features before committing further. Use the pricing configurator to include AI Studio and AI Assistant in your module plan, or contact the developer team if you want guidance on provider selection and rollout sequencing for your specific workflows.