FAQ & Glossary

Yes. Build a Gemini Gem — no approvals, no IT involvement, no cost beyond existing licensing. It works for internal audiences. How to build one.

There’s no approval process for building a chatbot. There is one rule, and it’s about data — see below.

Usually yes, even if you’re sure you want a managed chatbot. It’s the cheapest way to find out whether your content can actually answer your users’ questions — an afternoon rather than two months.

No. Gems only work for people with an ND Google account. If you need a public audience, you need a managed chatbot.

A Gem: an afternoon. A managed chatbot: 8–10 weeks if your content is already in good shape, 14–20 weeks more typically. The variable is nearly always content.

Talk to us first. There are data, accessibility, and procurement implications, and we may already have something that fits.

Use your unit’s own content freely. For data another unit owns, or anything restricted — student records, health, financial, or personnel information — get that data’s steward to approve the use first. This is the same whether you build it yourself or with us.

Ask the steward of that data before you use it. If you’re working with us, we’ll help you work out who that is and prepare the request. Start early — it’s rarely difficult, but it’s never instant.

No. Chatbots built through this toolkit answer from documents, not from student systems. Questions about someone’s records should always be routed to a person.

A Gem costs nothing beyond licensing the University already holds. For a managed chatbot, the University funds the platform and our time, and your unit pays for AI usage, charged back to a FOAPAL. You set a cap, so the spend is bounded. More on cost.

The chatbot stops answering and users get an error. You’ll have received notifications as you approached it. Set your cap against your busiest month rather than an average one, and make sure someone who can act is receiving the alerts.

Yes. These systems generate answers rather than looking them up, and they can be confidently wrong — particularly when the underlying content is missing, stale, or contradictory. That’s why testing is a real step and not a formality, and why every chatbot needs a visible route to a human.

Test properly before launch, including deliberately awkward questions. Keep a way to take it offline quickly. And don’t launch something that failed your own bar — the pressure to go live anyway is real, and it’s worth resisting.

Content problems are yours; platform problems are ours. Most problems turn out to be content. We’re available to consult either way — but we’re not monitoring your chatbot, so tell us.

It gets gradually more wrong while continuing to sound just as confident. That’s why we ask for a named owner and a review cadence, and why an unmaintained chatbot is a candidate for retirement.