Shared AI policies. Room for every department to build.
One AI platform for your whole campus. Set shared model and access policies while faculty and staff build assistants from selected course and campus materials.
Tell us your use case and desired scope; we'll follow up on requirements, security review, credit allocation, and rollout options. Submitting an inquiry does not start a trial or a contract.
Review security or request compliance reports through the Trust Center(opens in a new tab) .
Central policy boundaries. Local ownership for each assistant.
Set the guardrails, not the curriculum. Administrators define baseline boundaries; faculty and staff configure local assistants within them.
- Central administration sets the boundaries. An authorized administrator selects permitted models and sets sharing and access policies. Enforced policies and optional safeguard defaults are distinct. Organizations are isolated from one another; workspace, assistant, and collection permissions govern access within one.
- Course owners configure locally. Course owners select their own reading collections and teaching instructions within those policies. One course might use guided writing feedback; another, source-comparison questions. Departmental isolation is a permissions choice, not automatic.
- Each owner tests before sharing. Representative and out-of-scope questions run in preview. A configuration screen alone is not proof of enforcement, so check one policy consequence as a non-admin owner.
- Oversight stays aggregate. Assistant statistics show activity; organization reporting shows daily, member, assistant, and category credit spend. Neither opens private student conversations.
Aggregate activity and credit reporting are described under usage reporting; policy controls under governance.
Help people find the relevant policy or next step when the office is closed.
The same platform serves campus offices. Each assistant starts from a template and answers from the office's own approved documents.
-
Admissions & Enrollment
Answer after-hours questions from catalogs and deadline schedules with citations to official publications.
-
IT Helpdesk & Student Services
Answer common Wi-Fi, password, and software access procedures from maintained knowledge-base articles.
-
Committees & Governance
An access-controlled assistant grounded in bylaws, meeting minutes, and prior reports for policy lookup.
-
HR, Registrar & Policy Lookup
Reference employee handbooks and registration rules for onboarding and procedure questions.
Maintain one source collection per office and share it across teams where permissions allow. Assistants provide informational lookup, not automated admissions, financial aid, grading, or HR decisions, so configure and test a human contact route for unresolved questions.
A practical path to campus adoption.
Begin with a defined scope, clear stakeholders, and agreed criteria before expanding. Each institution adapts the stages to its own governance and review process.
-
Choose a starting point
Sponsor and local content owner select one course, department, or office and agree written criteria.
Produces:Use case + criteria
-
Set controls and ownership
IT and security reviewers check the FERPA attestation, SOC 2 Type 1 report, SSO, embed placement, and model availability.
Produces:Documented controls
-
Configure and test
The local creator adds materials, sets instructions, and runs representative, edge-case, and ambiguous prompts in preview.
Produces:Test set + refinements
-
Review before expanding
Sponsor, reviewers, and owners compare observations with the criteria and decide to expand, revise, or stop.
Produces:Go / revise / stop memo
What the evaluation measures
- Source correctness. Do responses reflect the sources, and are ungrounded questions handled responsibly?
- Task usefulness. Does the assistant handle repetitive questions and offer a clear human contact when it cannot?
- Accessibility and alternatives. Check contrast, scaling, and font settings, and keep non-AI alternatives for coursework.
- Maintenance and credit consumption. Track source-update effort and actual credit use against the allocated allowance.
Decide in advance
Agree these before the first test prompt, and write the exit terms into the proposal.
- Data boundaries: which materials and which people are in scope
- Duration and the stop criteria that end or expand the evaluation
- Who funds credits, and the allowance for the period
- Who maintains the source collections as documents change
- Accessibility checks and the non-AI alternative for coursework
Accessibility settings and their limits are described under accessibility features.
Discuss an evaluation scopeReady for your review process.
Documented controls and requestable compliance reports for privacy, security, identity, and procurement teams. Each card links to where the claim is documented.
Enforced at the organization level.
Identity requirements are set once and apply to every member. Requiring secure sign-in means password-only access is not allowed; invitation domain restrictions keep membership to institutional addresses; invitation lifetimes cap how long an unused invite stays valid. A configuration screen is a starting point for review, not proof by itself, so check one consequence as a non-admin member during evaluation.
Training commitment: Alkimi does not use customer content to train models, and model providers are configured for no-training use. No-training is distinct from retention and provider security controls, which are documented separately.
Review available reports, policies, the subprocessor list, and the security questionnaire through the Trust Center(opens in a new tab) . Some materials require a request; none are bespoke procurement documents.
Plan the cost of your rollout.
Review licensing, credit allocation, and usage controls for your deployment.
Institutional
Custom pricing for your deployment
Institutional pricing is scoped to deployment size, onboarding, support, and integration needs for departments and universities.
Custom pricing and credit allocation
Built around institutional needs
- Domain Verification
- Dedicated Support
- Onboarding & Training
- Custom Integrations
- Campus-wide licensing
Dedicated support, onboarding and training, and custom integrations are scoped in the proposal. The request button submits a requirements inquiry, not a purchase or trial.
Cost controls
- Per-message spend limits. Authorized owners set a model-message spend limit that also constrains available context. Separately metered tools can add charges, so review the cost breakdown and enabled tools; this is not an all-in ceiling.
- Usage reporting. Daily, member, assistant, and category credit tracking, exportable as CSV. Explore usage reporting
- Spend alerts. Administrators are notified at credit thresholds. Alerts and caps help monitor consumption; they are not hard departmental cutoffs or a guarantee of uninterrupted service after credits run out.
Evaluation questions
Questions institutions ask before an evaluation
Standardization, security review, identity, model and access governance, storage and deletion, existing platforms, approved content, and pricing scope.
Why standardize on Alkimi instead of letting each team adopt AI separately?
Alkimi gives institutions one governed platform for course and campus assistants. Administrators can enforce policies for model availability, roles, external sharing, public assistants, and citation sharing. Departments and faculty still manage their own materials and use cases, while organization defaults provide a consistent starting configuration.
What can our security and privacy teams review?
Alkimi publishes information about encryption, data retention and deletion, model-provider practices, authentication, subprocessors, and its shared-responsibility approach to student records. Customer content is not used to train models. Your team can request the third-party FERPA attestation, SOC 2 Type 1 report, and security-review materials through the Trust Center.
Which identity and authentication options are available?
Alkimi supports Google and Microsoft sign-in, native multi-factor authentication, passkeys, and organization-level MFA enforcement. Workspaces and role-based permissions control access to assistants, collections, and administrative settings.
How are models and access governed?
Organization administrators choose which supported models are available and can migrate assistants when that availability changes. Enforced policies control roles, external sharing, public assistants, and citation sharing, while optional safeguard defaults shape new assistant configurations. Institutions can contact Alkimi to enable EU in-region routing for eligible models.
How is customer data stored, retained, and deleted?
Alkimi hosts its service on Google Cloud and uses Cloudflare for network services. Customer data is encrypted with TLS 1.2 or later in transit and AES-256 at rest. Deleted collections are removed from active production, and customer data is deleted within 90 days after a subscription ends, including backup aging, with earlier deletion available by request.
Will Alkimi replace our LMS, SIS, or website platform?
No. Alkimi adds governed assistants to existing systems rather than replacing them. Institutions can distribute dedicated assistant links, add website widgets, or use iframe embeds in systems that allow them.
How do assistants stay focused on approved campus content?
Each assistant can use selected knowledge collections containing catalogs, handbooks, policy documents, support articles, or other maintained sources. Staff control retrieval scope, citations, and whether web search is disabled, available only when requested, or available when the assistant needs it. Collection and workspace permissions keep each office's content under the appropriate owners.
How do we start, and how is institutional pricing scoped?
Start with one bounded use case, clear owners, selected source material, representative questions, and agreed criteria for expanding, revising, or stopping. Institutional pricing is scoped to deployment size, credit allocation, onboarding, support, and integration needs, with invoicing options handled through the proposal. Assistant owners set model-message spend limits; enabled tools can add separate charges. Administrators use organization reporting and usage alerts to monitor consumption.
Take a summary to your colleagues.
Everything a Provost, CIO, CISO, or procurement reviewer needs to decide whether an evaluation is worth scoping, in one selectable block.
Forwardable evaluation summary
Select, copy, or print this block for colleagues. No sign-in or form required. Reviewed September 19, 2026.
1. Platform category and governance
- Category: Governed AI platform for higher education.
- Central controls: Allowed models, organization sharing policies, MFA enforcement.
- Local ownership: Academic departments and offices configure materials and instructions.
- Grounding: Selected materials and available citations help people inspect answers; generated behavior and important answers still require review.
2. Evaluation lifecycle (four stages)
- 1. Choose starting point: Bounded course, department, or office scope and agreed criteria.
- 2. Set controls and ownership: Review FERPA attestation, SOC 2 Type 1 report, SSO, and embed placement.
- 3. Configure and test: Add sources, set guided instructions, run a preview test set including out-of-scope questions.
- 4. Review before expanding: Compare observed accuracy and credit use against criteria; decide go, revise, or stop.
3. Security and privacy baseline
- Training policy: Alkimi does not use customer content to train models, and model providers are configured for no-training use.
- FERPA: Third-party FERPA attestation. The institution remains the custodian of education records; Alkimi acts as a service provider under the school official exception.
- Encryption and infrastructure: Hosted on Google Cloud with Cloudflare; TLS 1.2+ in transit and AES-256 at rest; tenant isolation via PostgreSQL row-level security.
- Audit and deletion: SOC 2 Type 1 report via the Trust Center. Customer data deleted within 90 days of subscription termination, including backup aging, or sooner on request.
4. Identity and LMS integration
- Identity: Google and Microsoft SSO, native passkeys, native MFA, role-based permissions.
- LMS: Works alongside the LMS via links, iframe embeds, and coursework exports (QTI, Moodle XML, Blackboard, Canvas CSV). No native LTI 1.3 gradebook or roster sync.
5. Commercial and cost governance
- Proposal scope: Deployment size, credit allocation, onboarding, support, integrations.
- Cost levers: Model-message spend limits, daily and per-member CSV usage exports, spend alerts. Enabled tools can add separate charges; these controls are not a hard monthly budget.
- Access and funding: Shared course assistants are funded by the owning organization. Individuals invited from outside the institution use their own plan; see billing for the edge cases.
- Evaluation: Agree owners, permitted data, credit funding, source maintenance, accessibility and non-AI alternatives, and expand/revise/stop criteria before rollout.
6. Key verification links
- Inquiries: https://alkimi.ai/contact-sales
- Security overview: https://alkimi.ai/security
- Trust Center (reports, policies, subprocessor list, questionnaire; some materials require a request): https://trust.alkimi.ai(opens in a new tab)
Start with your institution's next useful AI workflow.
Tell us what you want to evaluate, from a single course or campus service to department-wide use. Discuss technical fit, security review, credit allocation, and rollout options.
Compliance reports and the security questionnaire are available through the Trust Center(opens in a new tab) .